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

[Roger Shimizu]

On Mon, Dec 14, 2015 at 11:31 PM, Felipe Sateler <fsateler at debian.org> wrote:
> On 14 December 2015 at 11:20, Roger Shimizu <rogershimizu at gmail.com> wrote:
>> Dear systemd maintainers,
>>
>> Thanks for helping for the adjtimex systemd service file last time.
>> I write again because I find an issue related to the service file.
>>
>> When installing, adjtimex's postinst script will ask user whether to
>> start the service by debconf, for the service file currently (enclosed
>> here), it doesn't respect the debconf if user choose "No".
>>
>> I find a temporary solution to patch postinst to run "systemctl
>> disable adjtimex.service" if user choose not to start the service when
>> in "configure" mode.
>> I call it "temporary" because it will miss some rare case such as:
>> - installing adjtimex when in sysvinit and choose not to start the
>> service, then installing systemd to replace sysvinit, it but this
>> won't trigger adjtimex's postinst script to disable adjtimex's
>> service.
>
> I don't follow. What exactly is the current behavior, and how does the
> new systemd service file does not respect it? Please add more context.
>
> I'd even question the need to ask about enabling the service. If I
> don't want the service, why did I install the package? Admins can
> manually disable later if they don't want to run it.

Adjtimex service is for setting up time ticks/frequency in kernel, but
some user don't want to change ticks/frequency, but only want to print
those kernel variables, maybe changed by NTP client.
Please see bug #785208: https://bugs.debian.org/785208

I think this requirement is rare, but reasonable.
If reading debconf's result is wrong, I think another solution is to
split adjtimex into adjtimex-base and adjtimex-service.
But looks overhead because it's a tiny package already.

Cheers,
Roger