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