Hello Felipe Sateler and others. Thanks for your bug report. I've recently been looking into the kbd package and prepared an update in pkg-kbd git which should hopefully get uploaded soon. I'm interested in following up with another upload targeting the bug report you filed soon after that.
On Sat, Aug 22, 2015 at 05:04:38PM -0300, fsate...@debian.org wrote: [...] > Hi, > > Your package kbd has an initscript that is enabled in runlevel S, but > it does not provide a corresponding systemd service unit. > > Systemd generates units for all sysv init scripts that do not have a > corresponding systemd unit. By default, it sets > DefaultDependencies=yes, which means they get ordered after early > boot has finished. > > The problem is that to preserve the runlevel S semantics, systemd in > debian is currently[1] ordering all S services Before=sysinit.target. > This target is particularly early in the boot sequence, which means > that it is most of the time too strict. In turn, this means it is > fairly easy to end up with dependency cycles. For an example, see bug > [763315]. Do note that the cycle still exists with sysvinit, it is > just that systemd complains more loudly. The main reason I see for the kbd script being in rcS is probably because of the "disabled if setupcon from console-setup is available" code calling setfont. More on this later. > > Please add a systemd unit for the given service with the appropriate > dependencies, which most of the time will be less strict than > Before=sysinit.target. In other cases, the script is simply not > applicable in systemd, in which case the package should ship a > symlink to /dev/null as /lib/systemd/system/<initscript>.service. Unfortunately the kbd init script is quite complex and after pondering this a bit I see atleast three different parts that it could be split into: - vcstime.service Simply be responsible for the DO_VCSTIME part and start vcstime. - kbd-basic.service Do the basic console setup, as mentioned above. Does nothing if console-setup is installed (see HAVE_SETUPCON in init script). This part should possibly be installed into basic.target - kbd.service The remaining bits unconditionally handled by kbd init script, eg. setterm calling for console blanking etc. This part should go later into sysinit.target or maybe even as late as multi-user.target I do have a few doubts about the entire approach though. Reimplementing the equivalent functionality from the init script in native service files would not be trivial so I think the above would mean we also need to split up the init script somehow so the services can call the revelant bit of the script. I wonder if the "kbd-basic" bits works at all anymore. It's supposed to call setfont when console-setup is not around to take care of the initial console setup..... but I guess setfont needs some actual data to work on. This data seems to be in console-setup-linux package. The kbd package does not pull that in (and it can't easily depend on it, because the reverse dependency is already in place and would cause a loop). Maybe if it true it doesn't work then the "kbd-basic" bits of the init script should just be scrapped? While we're discussing scrapping things the remaining "kbd" part of the init script doesn't seem like it has been functional under systemd (ever?). Only a single person noticed and noone seemed to have rushed to fix it despite systemd becoming the default init with Jessie. Shipping an init script calling setterm, which is not part of kbd but util-linux, seems a bit mis-placed to me. (And moving it over to util-linux isn't trivial since it's a conffile referencing other conffiles named /etc/kbd/...) Additionally it is shipped with default values poking at things configured in a Debian-specific way under /etc/kbd/config rather than relying on sane defaults by the kernel and also making the "consoleblank=" kernel parameter effectively non-functional. Additionally Ubuntu seems to be patching this part as they seem to consider the Debian default configuration harmful. (They also promote the kbd Recommends: console-setup to a Depends. Not sure how the handle dependency loop, given console-setup deps on console-setup-linux which deps on kbd in Debian atleast.) Maybe we should just considder dropping this part as well? Basically dropping the entire init script is something I'd like to have opinions on from the current maintainers before implementing. If we go this route I'd suggest something along this path: - stop shipping the init script and it's configuration files: $ cat /var/lib/dpkg/info/kbd.conffiles /etc/init.d/kbd /etc/kbd/config /etc/kbd/remap (given those are conffiles, they'll still stay around on upgrades unless we implement rm_conffile handling which I suggest we do *not*.) - Add a NEWS entry stating that kbd init script has been transfered to the local system administrators responsibility, short description on the purpose of the script, short description on drawbacks of keeping it around, example commands for how to get rid of it. (rm -rf /etc/kbd /etc/init.d/kbd && update-rc.d kbd remove) - consider if we should ship a masking of kbd.service to prevent dependency issues, given the script has probably never really worked on systemd anyway. If so also mention how to reenable it on systemd in NEWS just in case (now that the current state in pkg-kbd git should actually work under systemd). That would mean new installs don't have the init script while upgrades get (more or less) unchanged behaviour. Comments welcome! Does this sound entirly crazy? Does someone have a suggestion for an alternative approach that might make sense? > > We have prepared a transition wiki page[2] explaining the issue in > more detail, and outlining some general guidance. Please refer to it > as it will have useful information. > > If you have any other doubts, feel free to ask in > pkg-systemd-maintain...@lists.alioth.debian.org > -- > > [1] > http://sources.debian.net/src/systemd/222-2/debian/patches/Add-support-for-rcS.d-init-scripts-to-the-sysv-gener.patch/ > [763315] https://bugs.debian.org/763315 > [2] https://wiki.debian.org/Teams/pkg-systemd/rcSMigration > > Regards, Andreas Henriksson
