On 5 Mar 2016 17:01, "Anton Zinoviev" <anton@lml.bas.bg> wrote:
>
> On Fri, Mar 04, 2016 at 03:08:39PM -0300, Felipe Sateler wrote:
> >
> > > Unfortunately, I will not be able to maintain this file or to update it
> > > in accordance with future changes in systemd. So I suppose that unless
> > > you or somebody else volunteers to maintain it, it will be better to
> > > continue without it.
> >
> > As long as the initscript does simple things, it should require very
> > little maintainance. While I can't commit to maintain it (I am no
> > expert in console matters), feel free to CC pkg-systemd-maintainers or
> > myself if you ever receive a bug about this.
>
> The reason I hesitate is that I am not a "normal" maintainer of
> console-setup. While I have enough time for development related to
> console-setup, my limitations force me to allocate this time in batches
> with relatively large periods between them. In fact, it won't be
> incorrect to say that most of the time other people take care of this
> package (one can easily observe this in the changelog).
As long as the systemd service keeps relatively close to what the init script is doing, keeping the service file up to date is easy. The only problematic parts would be if the dependencies are changing; but then there are people that can answer questions.
It would be a bit harder if the systemd units and init scripts start diverging.
>
> > >> Before=local-fs-pre.target
> > >> Wants=local-fs-pre.target
> > >
> > > What is the meaning of these two?
> >
> > This ensures it is run before systemd attempts to fsck and mount any
> > local filesystems. It is therefore a relatively appropriate
> > replacement for the checkroot dependency.
>
> What does 'Wants' do? Is this some kind of optimization?
Wants means that whenever the service is started, the listed dependencies should be started as well.
In systemd, ordering and functional dependencies are orthogonal, so there are separate keywords to specify both. Ordering dependencies do not mean that all the listed services will be activated, it only means: if these units are part of the same transaction, then start them before (or after) the declaring unit. The functional dependency means that if the service is to be started, the listed units will be added to the transaction.
In this case, there is a small optimization: mounts and fsck services are ordered after local-fs-pre, but do not depend on it. Thus on simple scenarios the target is never incorporated into the boot transaction. Services that should run before need to cause the target to be pulled in explicitly, which is why keyboard-setup.sh would need to Want it.
There are more details about the target in the systemd.special manpage, and about dependencies in systemd.unit.
>
> > There does not appear to be a keymap init script:
> >
> > These are created by the kernel when devtmpfs is mounted, and systemd
> > mounts /dev before starting any units, so they should be available,
> > yes.
>
> This is good. It seems we don't need 'After'.
Right, it can be started as early as possible (and keymap removed from the init script).
>
> > > One novelty in version 1.138 is that it is unnecessary to run setupcon
> > > in order to configure the console. It is OK to configure the keyboard
> > > in this way, but this usually will be slower than what the script
> > > keyboard-setup.sh does -- instead of setupcon it runs
> > > /etc/console-setup/cached_setup_keyboard.sh and reverts to using
> > > setupcon only when this script doesn't exist of fails.
> >
> > IMO, the init script should be as dumb as possible, as it is a
> > conffile. Therefore all program logic should move outside the script
> > and into a helper script that lives in /lib. This way, improvements
> > are guaranteed to be shipped to users.
>
> The script /etc/console-setup/cached_setup_keyboard.sh is not a
> configuration file and the user is not supposed to edit it. Since it is
> autogenerated, there is no problem to ship improvements to the users.
> (Under FHS this script would have to go in /var rather than in /etc,
> however, we need it while /var is not yet mounted. Years ago, nobody at
> debian-devel could find a solution to this problem, so now console-setup
> violates this aspect of FHS.)
I meant the logic to determine if setupcon or the cached scripts should be run. If in the future that part is changed (eg, the names are changed, or more scripts are generated), there is no guarantee the change will reach users, since they may have modified the init script.
>
> > The resulting unit would be:
> >
> > ConditionPathExists=/bin/setupcon
>
> Is there a possibility to use something like 'ConditionPathDoesntExist?
> If yes, then we can use two units like these:
>
> Unit 1:
>
> ConditionPathExists=/etc/console-setup/cached_setup_keyboard.sh
> ExecStart=/etc/console-setup/cached_setup_keyboard.sh
>
> Unit 2:
>
> ConditionPathDoesntExist=/etc/console-setup/cached_setup_keyboard.sh
> ConditionPathExists=/bin/setupcon
> ExecStart=/bin/setupcon --keyboard-only
Yes, it can be done. The syntax is to prepend a ! To the path (ConditionPathExists=!/etc/console-setup/cached_setup_keyboard.sh). Multiple ConditionPathExists stanzas are ANDed together (mostly, you can add | prefix to cause OR, see man systemd.unit for details).
However, this is not exactly the same: if the cached script fails, then setupcon would not be run.
Also, I would advise against having different logic in the systemd services than in the init scripts: the maintenance burden is higher, and requires a higher initial understanding from people not already familiar with the package.
Saludos