[systemd-devel] PATCH: handle SYSTEMCTL_OPTIONS in systemctl

[Frederic Crozat]

Le jeudi 17 janvier 2013 à 13:59 +0000, Colin Guthrie a écrit :
> 'Twas brillig, and Frederic Crozat at 16/01/13 17:15 did gyre and gimble:
> > Yes, we have a similar patch in /etc/rc.status on openSUSE, which is
> > using SYSTEMCTL_OPTIONS as variable name. So far, I haven't found a case
> > where --no-block was needed, only "--ignore-dependencies" was needed
> > (which is why I used a catch-all variable name, just in case
> > "--no-block" would be needed later, so we wouldn't need to release
> > another version of the package shipping /etc/rc.status).
> > 
> > But it is no longer enough because we started to migrate some
> > initscripts to systemd unit and our YaST tools have also learned to call
> > systemctl to start / stop services. And because of that, the
> > "workaround" in /etc/rc.status is no longer effective. And YaST team
> > doesn't handle to handle the "SYSTEMCTL_OPTIONS" workaround in their
> > generic service handling code (I can understand that).
> 
> It feels kinda weird that --ignore-dependancies is the right solution
> here. I would have thought that --no-block makes more sense generally.
> Ignoring deps when starting a job could easily lead to failures, but if
> you just want to start something and not necessarily wait for it to be
> available, --no-block seems the better solution to me.
> 
> I guess it very much depends on where you are using it and for what
> purposes, but as mentioned in the man page --ignore-dependencies "is
> mostly a debugging and rescue tool for the administrator and should not
> be used by applications" which makes me wonder if --no-block might be
> the better solution to at least some of your problems.

IIRC, it was tested and it didn't help (probably because those blocking
services were waiting for a dependency, like network being up, which
wasn't visible at the systemd level). Moreover, using --no-block, you
can't be sure the service you just started has been really started
(which can be problematic). But it might be worth investigating again if
--no-block could be used for calls from inside network hooks (although
it would delay those services execution after the network service is
complete, unlike the solution we have ATM).

Initially, we were "unwrapping" initscripts (ie not starting them under
systemd) instead of --ignore-dependencies, because it was only done
during "2nd stage" of our installer (ie not often and before those
services would be "normally" started by systemd). Now, services are
handled through systemd but we are still stucked due to the "pending"
queue of services to be started by systemd. And if, for instance, the
"2nd stage" installer is starting sshd to allow remote installation, you
can't really use --no-block because sshd won't be started. Again, it is
not a definitive answer, but so far, it is the one which has proved to
be working for us.

-- 
Frederic Crozat <fcrozat at suse.com>
SUSE