[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: systemd-fsck?



Bas Wijnen wrote:
> On Mon, May 12, 2014 at 09:19:40AM -0700, Josh Triplett wrote:
> > Having libpam-systemd depend on "systemd-shim | systemd-sysv" will not properly
> > handle systems that already have systemd installed but not systemd-sysv.
> 
> I don't think I understand what you mean.  What does "having systemd installed"
> mean, if not that it's being used as the init system?  And if it isn't used as
> the init system (presumably because the user chose no to do that), why is it a
> good idea to change that?
> 
> In other words: what isn't handled properly?  What should happen, and what does
> happen?

Consider a system which has systemd installed, systemd-sysv *not* installed,
and systemd used as PID 1 via init=/bin/systemd.  Since systemd-sysv is not
already installed, "systemd-shim | systemd-sysv" will pull in systemd-shim
instead, which will atttempt to supply services that conflict with systemd's.

It might be possible to make an installed systemd-shim play nice with an
installed and running systemd, and that'd be needed to allow sysvinit-core and
systemd to coexist on the same system as something the user can select.

> > > That being said, I don't really care much about the init system; sysv worked
> > > fine for me, and now I apparently have systemd and it doesn't seem to cause
> > > problems either.
> > 
> > Given the lack of a massive number of new bug reports against either
> > systemd packages or the desktop packages depending on them, I suspect
> > that's the general result, as well: uneventful upgrade to a system
> > that's still sysvinit-compatible, where we can deal with bugs as they
> > come up.
> 
> Yes, and it's good that upgrades are generally smooth, but I don't like the
> idea to migrate people by default.  As long as the other init systems are
> supported, there's no reason that we should push our users away from them.  If
> there are problems with them that aren't fixed, then we should stop supporting
> them.  As long as that hasn't happened, users should be free to use the other
> init systems and not be treated as second class.

There *is* a reason we should push our users away from the non-default
init: we want to make sure that only the users who specifically *want* a
non-default init run one, and those are exactly the users prepared to
deal with the additional challenges and support issues with doing so.
Uers who don't care should end up running the default init system.  It's
easy enough for any user who *does* care to select a different set of
installed packages.

- Josh Triplett


Reply to: