On Mon, May 23, 2016 at 6:21 PM, Lennart Poettering <lenn...@poettering.net> wrote: > On Mon, 23.05.16 18:16, Ashish Sangwan (ashishsangw...@gmail.com) wrote: > >> On Mon, May 23, 2016 at 2:13 PM, Lennart Poettering >> <lenn...@poettering.net> wrote: >> > On Mon, 23.05.16 13:30, Ashish Sangwan (ashishsangw...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
