[systemd-devel] Fwd: Handling ExecStop failure

[Ashish Sangwan]

On Mon, May 23, 2016 at 6:21 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Mon, 23.05.16 18:16, Ashish Sangwan (ashishsangwan2 at gmail.com) wrote:
>
>> 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?
>
> Yeah, the assumption is that for fuse-based file systems the
> mount.<fs> logic implemented in the /usr/bin/mount utility is used:
> i.e. it already supports invoking external helpers for specific file
> systems anyway.
>
>> > 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?
>
> As discussed in the other mails in this thread: maybe this is simply
> confusion about what "console" in StandardOutput=console+journal
> actually means. It does not mean the tty that you invoked "systemctl"
> from. Instead, it literally means /dev/console, i.e. the kernel's
> console device, wherever that may point to. if you are running a
> graphical UI of some kinda, /dev/console is usually not seen.

Yeah, you are right. /dev/console is there but it is not used.
The bash shell on which systemctl is executed is using /dev/pts/X
So I used the StandardOutput=tty option and set TTYPath=/dev/pts/X
and it worked. But the issue is we cannot hard code the TTYPath in the unit
file as the "X" in /dev/pts/X keeps changing. It could be 0/1/2 and so on.

Thanks,
Ashish

>
> Lennart
>
> --
> Lennart Poettering, Red Hat