Package: systemd
Version: 37-1
Severity: wishlist

Currently, systemd masks or overrides most of the scripts in initscripts
in favor of its own native implementations:

~$ dpkg -L initscripts | grep '^/etc/init\.d/' | while read x ; do test -e 
"/lib/systemd/system/$(basename $x .sh).service" && echo $x; done
/etc/init.d/hostname.sh
/etc/init.d/checkfs.sh
/etc/init.d/mountnfs.sh
/etc/init.d/mountdevsubfs.sh
/etc/init.d/mountnfs-bootclean.sh
/etc/init.d/checkroot.sh
/etc/init.d/single
/etc/init.d/mountkernfs.sh
/etc/init.d/mtab.sh
/etc/init.d/bootmisc.sh
/etc/init.d/reboot
/etc/init.d/mountall.sh
/etc/init.d/halt
/etc/init.d/killprocs
/etc/init.d/mountall-bootclean.sh
/etc/init.d/urandom
/etc/init.d/rmnologin

However, not all of them:

~$ dpkg -L initscripts | grep '^/etc/init\.d/' | while read x ; do test -e 
"/lib/systemd/system/$(basename $x .sh).service" || echo $x; done
/etc/init.d/rc.local
/etc/init.d/mountoverflowtmp
/etc/init.d/sendsigs
/etc/init.d/umountroot
/etc/init.d/umountfs
/etc/init.d/skeleton
/etc/init.d/bootlogs
/etc/init.d/umountnfs.sh

systemd already handles the functions of sendsigs, umountroot, umountfs,
and umountnfs.sh, to the extent they need handling; please go ahead and
mask those.

systemd has code to handle rc.local as well, but doesn't enable it on
Debian; please enable that for Debian and mask /etc/init.d/rc.local from
initscripts.

bootlogs does two things: update motd (which seems misplaced) and save
kernel messages to /var/log/dmesg.  systemd's logging completely
supersedes the need for the latter.  systemd also handles the former in
a different way, but in any case a simple systemd service could easily
preserve the existing handling of motd.  So, please mask bootlogs and
optionally handle the existing motd functionality.

That just leaves mountoverflowtmp.  Bug 653329 argues that it shouldn't
exist at all, which I'd agree with.  Debian also already provides the
option of mounting a tmpfs there all the time, which would make
mountoverflowtmp unnecessary.  Also, I don't think the issue of filling
up /tmp affects login as much as it may have in the past.  Desktop
environments already provide umpteen warnings about filling up the
filesystem.  And as far as I know, text-based logins work even with no
/tmp (unless someone does something monumentally stupid with PAM), so
SSHing to a server should always work, as should switching to a VT.  I
checked with systemd upstream, and they specifically don't want to have
such functionality by default.  Kay Sievers recommended just having
tmpfs on /tmp as the default (as Debian currently does and systemd
upstream will do in the future), and letting people who override that
default keep both pieces if they fill up the filesystem.  So, I'd
suggest masking mountoverflowtmp in systemd.

With all of those services masked or overriden, I think that systemd
could then drop its dependency on the initscripts package.

Thanks,
Josh Triplett

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages systemd depends on:
ii  initscripts         2.88dsf-22
ii  libacl1             2.2.51-5
ii  libaudit0           1:1.7.18-1.1
ii  libc6               2.13-26
ii  libcap2             1:2.22-1
ii  libcryptsetup1      2:1.3.0-3.1
ii  libdbus-1-3         1.4.16-1
ii  libpam0g            1.1.3-7
ii  libselinux1         2.1.0-4.1
ii  libsystemd-daemon0  37-1
ii  libsystemd-login0   37-1
ii  libudev0            175-3
ii  libwrap0            7.6.q-22
ii  udev                175-3
ii  util-linux          2.20.1-1.2

Versions of packages systemd recommends:
pn  libpam-systemd  <none>

Versions of packages systemd suggests:
pn  python       2.7.2-10
pn  systemd-gui  <none>

-- no debconf information



-- 
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

Reply via email to