[systemd-devel] Fwd: Handling ExecStop failure

[Ashish Sangwan]

On Mon, May 23, 2016 at 2:13 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> 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.

I am not sure but if I use .mount unit than I won't get to execute the file
system binary because ExecStart/Stop is not available in .mount?

>
>> 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.

Ok, we have solved the first issue using your suggestion. Thanks.

>
>> 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?

Yes, it generates the log in journal. To make sure it is not my program which
is the culprit I made a really *simple* script which just echo a
single line and invoke it
using systemctl start/stop. Still the output is not getting printed on
the console.
Could you suggest some debugging steps which I can try to root cause the issue?

Thanks for the help!

>
> Or maybe something is obstructing or redirecting console output?
>
> Lennart
>
> --
> Lennart Poettering, Red Hat