On Sun, 26.01.14 17:23, Tom Gundersen (t...@jklm.no) wrote: > > I rebuilt systemd without this restriction, set KillMode=process for > > user@.service and this fixed things here. > > > > So there are two problems associated with user instance. > > > > 1. Using KillMode=control-group is wrong. Each service managed by user > > instance has own requirements how it is stopped. Just sending everything > > SIGTERM without even trying service ExecStop first is obviously > > incorrect. > > I guess what we want is to first send SIGTERM only to the systemd > --user process, and only after a timeout start sending SIGTERM to all > the processes in the control group? I.e., wouldn't a ExecStop entry in > user@.service give us the required timeout?
Well, it would, but I am really sure KillMode=mixed would be the better approach... > > > 2. user@.service has single timeout, but it manages unknown in advance > > number of services each needing unknown timeout. While having some > > capping to total timeout looks sensible, only user itself may estimate > > the value. But service user@.system is system-level service which use > > cannot configure ... > > I think it really makes sense to have a system-wide timeout on these > things (possibly a high one), we don't want the user to delay things > without limit. The user already has the possibility of putting their > own limits if they want to (but they must of course be shorter than > the system-wide one). Yeah, I fully agree. We need a timeout here that is mandated by the system, and cannot be overridden, so that the user cannot find a way to circumvent kill requests by the admin. However, it certainly makes sense to make it a bit higher than the systemd user instance's own timeouts. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
