Bug#591791: systemd point of view
Hi,
Steve, first I'd like to thank you for bootstrapping this discussion and
proposing the policy text. It's a good start.
I thought I should chime in about what I envision for systemd in Debian
so we can make sure we end up with no conflicts between upstart's and
systemd's implementations in Debian. I haven't subscribed to the bug
report from the start, so I'll try to summarise and copy and paste from
various replies in the bug.
]] Kurt Roeckx
| A lot of the scripts currently in /etc/rcS.d/ come from the
| initscripts package. Is the alternative supposed to implement all the
| functionality by those scripts? Or do we expect them to run the
| scripts from /etc/rcS.d/ as 9.3.4. seems to suggest?
systemd blacklists some of them, but run the rest as normal init scripts
that are needed before we reach sysinit.target, then the normal runlevel
scripts are run.
| /etc/init seems to be a very general directory name for an upstart
| job. Can the alternatives use the same job files as upstart?
systemd can't, at least. We use /etc/systemd so while I dislike the
namespace grab of upstart, it won't cause any problems for systemd.
(It also breaks tab completion for those of us who like to run init
scripts by hand, which is going to affect everybody, but initramfs-tools
already did that so that damage is done already.)
>From the proposed policy patch:
+ SysV init scripts for which
+ an equivalent upstart job is available must query the output of
+ the command <prgn>telinit --version</prgn> for the string
+ <tt>upstart</tt> and avoid running in favor of the native
+ upstart job.
My system actually already has upstart installed, but doesn't use it, so
upstart's telinit will have to be fixed to not report «upstart» in its
version string if the running init is not upstart. That's slightly
orthogonal to this bug report, but it shows that you can't necessarily
depend on the output of --version and such to know what's running. This
will also affect people on migration from one init system to another.
+ Dependency-based boot managers for SysV init scripts, such as
+ <package>insserv</package>, may bypass a given init script
+ entirely when an equivalent upstart job is present, to avoid
+ unnecessary forking of no-op init scripts.
What happens to the dependency resolution of insserv in that case? I'd
much rather have insserv not do anything and the non-sysvinit init
system be smart and parse LSB headers rather than insserv seeing that A
depends B, but B is missing (since it's provided by a systemd
service/upstart job) and then flake out.
I'd also like us to forbid depending on implementation-specific scripts
such as mountkernfs since there won't necessarily be anything that maps
to in a non-sysvinit world. The exception would be if an init script is
shipped as part of the init system, so sysv-rc's scripts could have
dependencies on mountkernfs, but random daemons could not.
A final thing I'd like to get added to the policy text is how
standardised facility names are handled. insserv for some reason does
not handle init scripts providing $x-display-manager and similar, but
requires those to be added to the insserv configuration file. We should
either require init implementations to allow providing the standardised
facility names or we should put that information somewhere in a a
neutral location and format so all init implementations can make use of
it.
Best regards,
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Reply to: