[Pkg-kbd-devel] Bug#796583: kbd: Has init script in runlevel S but no matching service file

[Andreas Henriksson]

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, fsateler at 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-maintainers at 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