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? > >> 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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
