[systemd-devel] Fwd: Handling ExecStop failure

[Lennart Poettering]

On Mon, 23.05.16 13:30, Ashish Sangwan (ashishsangwan2 at gmail.com) wrote:

> The first issue is, once the command mentioned in ExecStop failed due
> to mountpoint busy, the user comes out of the mountpoint, making it
> un-busy and again fires the systemctl stop command, however the status
> of the service is not changed, it remained in failed state and the
> mountpoint remains mounted.

Service stop executables failing just indicate to systemd that the
service failed. If this happens, systemd will kill all remaining
processes of the service and then put the service in "failed" state.

I think the source of the confusion here is really that you are using
a .service unit to model a mount point, where you really should be
using a .mount unit. For regular mounts systemd will actually notice
that the mount point continues to exist according to
/proc/self/mountinfo after the stop command failed, and thus not
actually consider the unit down if the ExecStop= command failed.

> We have to explicitly do umount and kill the process to clean it.
> How can I avoid this issue so that once the mountpoint becomes
> un-busy, executing systemctl stop again will complete successfully.

You can't right now, and I am not sure this should be supported. For
safety reasons systemd does not permit services to refuse shutting
down, which I figure is what you are asking for here... I mean, if the
system is to be powered off, how would systemd even react to a service
refusing to go away?

Note that systemd has a concept of ordering dependencies, which allow
you to make sure that the stuff accessing your mount is terminated
before you remove the mount. For example, something like
Before=systemd-user-sessions.service is often already enough to
add. This orders your service to be started before the service that
permits user log-ins. Since in systemd start-up order is always the
inverse of the shutdown order this means that at shut-down your
service is stopped only after user sessions ended.

> My second issue is, on failure of stopping/umounting, no failure
> message appears on console although I have used StandardError
> option.

Maybe your program code detects whether it is connected to a TTY or
not, and behaves differently, for example logs directly via syslog()
when it is not connected to a tty? (note that if you use
StandardOutput=console+journal you are only indirectly connected to
the console, through a socket to journald). Do you see the logs it
generates in the journal at least?

Or maybe something is obstructing or redirecting console output?

Lennart

-- 
Lennart Poettering, Red Hat