On Tue, 03.02.15 22:22, Michael Biebl (mbi...@gmail.com) wrote: > 2015-02-03 22:10 GMT+01:00 Lennart Poettering <lenn...@poettering.net>: > > I don't see how this would apply to non-sysv code. I mean, code that > > is written with systemd semantics in mind should be able to issue a > > service reload during any time it wants to, if it keeps the ordering > > issues in mind. For example, if I have a service that has > > DefaultDependencies=no (and hence ordered against nothing at all by > > default), and I want to issue systemctl reload on it, knowing that > > this cannot really deadlock, since there are no deps that could cause > > deadlocks, then i should be able to do so. With your patch you turn > > these reloads into NOPs... > > During shutdown (and early boot), yes. But why would you want to > schedule a restart or reload during shutdown?
Well, we try to keep reloads out of the default codepaths, but it's easy to construct cases where people might want to deviate fromt the default codepaths. > Do you have a real-world example for that? Consider systemd-journald.service. It's a service with DefaultDependencies=no. We don't terminate it as part of the normal shutdown, we leave that to the final killing spree, so that we have logging for as long as possible. Now, people might want to hack something up that changes journald configuration to forward logs to kmsg during the last part of shutdown, so that they can see it in netconsole or so. SO they write their little service that patches journald.conf and restarts journald, and this is done during shutdown from a normal service's ExecStop= line. This normally works fine, since journald is not ordered against anything that matters. But it doesn't work on Debian, because on Debian there's no way anymore to restart journald as soon as shutdown commenced... While I just made this scenario up I think it's actually quite realistic, and I think it's a valid thing for admins to do.... > The thing is, you have to be extra careful to never, ever call a > restart/reload from such hook scripts. If those are triggered via > service or systemctl on a native or SysV script doesn't make a > difference. It is completely fine to enqueue restarts and reloads from hook scripts. However the emphasis is on *enqueue*. The issue is that you block on it, you shouldn't do that. On Fedora, iscsi is reloaded from an NM callout. If you ask me that's frickin' ugly, but it *is* supported as long as iscsi's reload is queued asynchronously instead of requested synchronously. In Fedora, the logic to make this async sits on the client side of things, it's not enforced by the engine in PID 1. The same really applies to Debian too... > It's simply to easy to cause a dead lock this way, and I think systemd > should try much harder to avoid such situations. Well, it would be great if we could solve the halting problem. But we can't. I mean, I am all ears regarding adding deadlock detection code. But I am really not convinced that breaking the engine for *everybody* just because *some* clients are weird is an option. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
