systemd and sysv init incompatibilities

Doug Ledford dledford at redhat.com
Thu Feb 23 18:10:57 UTC 2012


On 2/23/2012 8:52 AM, Michal Schmidt wrote:
> On 02/21/2012 06:31 PM, Doug Ledford wrote:
>> it honors all the LSB dependency tags in the SysV init scripts, and
>> my experience is that this is specifically where a number of the
>> emulation startup bugs exists.
> 
> What do you mean? That the LSB headers are incorrect too often?
> It's a problem, but that at least should not be too hard to fix.

No, the LSB headers can be correct, they are simply not honored in all
cases.  For instance, look at my rdma init script in the rdma package.
Even though I list all the things that are required-stop, those things
are not always stopped before systemd tries to stop the rdma service,
and this causes the rdma service to fail to stop properly.  And in the
opensm init script it calls out for $rdma to be started first, yet
systemd was starting opensm first (this was on Jay's machine, I'm
running rhel, so this bit is second hand knowledge anyway).

>> Furthermore, the design "feature"
>> of not stopping anything that it didn't start seems to be more of
>> a bug than a feature to me...it means that if an admin starts a
>> service manually for whatever reason (debugging, want to see output,
>> the systemd unit file won't allow the necessary interactive username
>> and password prompt, etc.), then it won't get stopped properly on
>> shutdown.
> 
> Processes that are still around after stopping the services systemd
> knows about will get a SIGTERM and after 5 seconds a SIGKILL if they
> refuse to die.

That is nowhere *near* the equivalent of running a service's shutdown
script.  Some scripts do lots of stuff on shutdown.  Just look at my
rdma service script.  The assumption that just because systemd didn't
start it that it does not deserve a clean shutdown is, at best dumb, at
worst could actually cause loss of data.  How did anyone think that
doing something that could possibly cause loss of data in the name of
performance optimization, especially in a totally non-performance
critical path, was anything other than a dumb idea?

>> That is not a feature, that's just dumb.
> 
> I disagree.

"I disagree: if I agreed with you, we would both be wrong" - One of my
t-shirts

-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: 0E572FDD
	      http://people.redhat.com/dledford

Infiniband specific RPMs available at
	      http://people.redhat.com/dledford/Infiniband

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 898 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120223/c9bc51d3/attachment-0001.sig>


More information about the devel mailing list