Bug796588#: adjtimex: Has init script in runlevel S but no matching service file

Felipe Sateler fsateler at debian.org
Sat Nov 28 15:44:10 GMT 2015


Hi Roger,

On 28 November 2015 at 11:12, Roger Shimizu <rogershimizu at gmail.com> wrote:
> Dear systemd maintainers,
>
> I'm in the process of ITA adjtimex package, which contains a bug you
> reported that need to support rcS service. I'm trying to fix this
> before send out my 1st release to close ITA.

Excellent!

>
>> Package: adjtimex
>> Severity: important
>> User: pkg-systemd-maintainers at lists.alioth.debian.org
>> Usertags: init-rcs-service
>> Your package adjtimex has an initscript that is enabled in runlevel
>> S, but it does not provide a corresponding systemd service unit.
>
> As you may already know, adjtimex is a tool to set up kernel time
> variables in boot time. Correct time and time ticking is important to
> many services, including time-sync service, so in SysV world adjtimex
> is run in rcS level, which is very early.
>
> Enclosed the "adjtimex.service" file I wrote and confirmed working
> well on my box.
> Since this is the first time I write service file, it would be helpful
> if you can help to review it.

I have some comments:

> [Unit]
> Description=adjtimex service in early boot

I think the description of the init script is better: "set the kernel
time variables".

> ConditionFileIsExecutable=/etc/init.d/adjtimex

I thin this is superflous.

> DefaultDependencies=no
> After=local-fs.target
> Before=time-sync.target sysinit.target shutdown.target
> Conflicts=shutdown.target

I'm not sure about time-sync.target. `man systemd.special` says that
time-sync.target is for synchronizing against a remote source, which
AFAICT adjtimex doesn't do. Note that if what you wanted to do is to
run before other time-synchronization daemons, this will not do it.

sysinit.target should be ok, though.
I don't think the conflict/before with shutdown.target is relevant, as
this unit does nothing on stop, and thus does not need to do anything
on shutdown.

>
> [Service]
> Type=oneshot
> ExecStart=/etc/init.d/adjtimex start

I think you should call the program directly and bypass the init
script. You can do as follows:

# default values
Environment=TICK=10000
Environment=FREQ=0
# override as in the init script
EnvironmentFile=-/etc/default/adjtimex
ExecStart=/sbin/adjtimex -tick $TICK -frequency $FREQ

> TimeoutSec=0

This is almost certainly wrong. I think you should skip this entry and
leave it at the default. At some point the system needs to continue
booting, even if the time is wrong, no?

> StandardOutput=tty

Do not set this, as this overrides the administrator default in
/etc/systemd/system.conf. Let standard output go to the system-wide
default.

> #RemainAfterExit=yes

I have seen that Type=oneshot services that do not have
RemainAfterExit=yes can be executed multiple times during boot. This
may or may not be a problem here.

>
> [Install]
> WantedBy=sysinit.target

>
> I also have one doubt whether to have "RemainAfterExit=yes", which is
> commented out now.
> After setting the kernel time variables, adjtimex simply exits and
> don't need to remain as daemon. I guess it should be okay to be "no".

The RemainAfterExit directive controls wether systemd considers the
unit "active" after all the running processes in the unit exited. This
can trigger multiple runs during boot, if at some point this unit is
wanted, but it already ran and exited. My sense is that
RemainAfterExit should be =yes for most Type=oneshot service.
Unfortunately, that means that to manually re-run the unit, one needs
to do a "restart" instead of a "start" to make systemd run the program
again.

>
> Looking forward to your reply. Thank you!

Thank you for your contribution!


-- 

Saludos,
Felipe Sateler




More information about the Pkg-systemd-maintainers mailing list