I noticed that tmp unmount failed even if I rebooted immediately after booting up. The reason was vmware initscript. Script partially failed because no drivers were present in currently running kernel. Still some stuff was started. But apparently because systemd believed service has failed, it did not try to stop it:
/tmp: 1814 UID PID PPID C STIME TTY TIME CMD root 1814 1 0 20:41 ? 00:00:00 /usr/bin/vmware-usbarbitrator vmware.service - LSB: Manages the services needed to run VMware software Loaded: loaded (/etc/rc.d/init.d/vmware) Active: failed since [Tue, 05 Oct 2010 20:41:41 +0400; 3min 36s ago] Process: 1770 (/etc/rc.d/init.d/vmware start, code=exited, status=1/FAILURE) CGroup: name=systemd:/systemd-1/vmware.service └ 1814 /usr/bin/vmware-usbarbitrator Traditional sysvinit would have stopped it anyway. Notice that cgroup is still available and contains some processes for this service. So what would be the right behaviour in this case? a) try to stop failed service anyway - that would be compatible with traditional initscripts handling b) try to stop failed service if it has some processes running _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
