Bug#1009963: deb-systemd-helper: Misleading error message in "sub enable" if systemctl fails

[Sascha Herrmann]

Package: init-system-helpers
Version: 1.60
Severity: normal
X-Debbugs-Cc: sh-...@ps.nvbi.de

Dear Maintainer,

the code line 'or error("systemctl preset failed on $scriptname: $!");' prints
some misleading information, if the systemctl command fails and returns an
return value != 0. When using the systemctl package (systemctl-replacement),
some packages fail to setup their service files, systemctl returns the error
code 1 which results in a message like

"/usr/bin/deb-systemd-helper: error: systemctl preset failed on keyboard-setup.service: No such file or directory"

The "No such file or directory" is produced by the $! part of the error string,
but $! isn't actually set by the system() call. The wrong (and random) error
messages gives wrong hints, when searching for the root cause of the problem
triggering the failure to install the service file. $! should only be used if
the system() call returned -1.

Thanks,
Sascha


-- System Information:
Debian Release: 11.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/1 CPU thread)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages init-system-helpers depends on:
ii perl-base 5.32.1-4+deb11u2

init-system-helpers recommends no packages.

init-system-helpers suggests no packages.

Versions of packages init-system-helpers is related to:
pn insserv <none>

-- no debconf information

[Michael Biebl]

Am 21.04.22 um 12:33 schrieb Sascha Herrmann:

> Package: init-system-helpers
> Version: 1.60
> Severity: normal
> X-Debbugs-Cc: sh-...@ps.nvbi.de
>
> Dear Maintainer,
>
> the code line 'or error("systemctl preset failed on $scriptname: $!");' prints
> some misleading information, if the systemctl command fails and returns an
> return value != 0. When using the systemctl package (systemctl-replacement),
> some packages fail to setup their service files, systemctl returns the error
> code 1 which results in a message like
>
> "/usr/bin/deb-systemd-helper: error: systemctl preset failed on keyboard-setup.service: No such file or directory"
>

So /usr/bin/systemctl is provided by the "systemctl" package?
Can you post the output of
apt-cache policy systemctl

Please uninstall the systemctl package and test if the failure is gone.

Regards,
Michael

[Ansgar]

Hi,

On Thu, 2022-04-21 at 18:13 +0200, Michael Biebl wrote:
>
> So /usr/bin/systemctl is provided by the "systemctl" package?
> Can you post the output of apt-cache policy systemctl

I think the bug reporter suggest to replace the

system(...) == 0 or error("systemctl preset failed on $scriptname: $!");

with a more correct (and verbose)

system(...);
if ($? == -1) {

error("systemctl preset failed on $scriptname: $!");
}

elsif ($? & 127) {
error("systemctl preset died with signal " . ($? & 127));
}
else {
error("systemctl preset failed with return status " . ($? >> 8));
}

as `perldoc -f system` suggest. (Untested, so might contain typos and
the like.)

Currently it always give "$!" as the reason, even when not correct.
This would also be incorrect if the real systemctl is used if the
command fails because of syntax errors or so.

Ansgar

[Michael Biebl]

Am 21.04.22 um 18:37 schrieb Ansgar:

Thanks for the additional information, Ansgar.

I guess we have two issues then:
- systemctl (from docker-systemctl-replacement) most likely not being
compatible with the real systemctl
- handling of the return code from system()

We do have quite a few calls to system() in our perl code.

[sh-...@ps.nvbi.de]

On Thu, 21 Apr 2022 19:08:26 +0200 Michael Biebl <bi...@debian.org> wrote:

> > ...

> >
> > Currently it always give "$!" as the reason, even when not correct.
> > This would also be incorrect if the real systemctl is used if the
> > command fails because of syntax errors or so.
>
> Thanks for the additional information, Ansgar.
>
> I guess we have two issues then:
> - systemctl (from docker-systemctl-replacement) most likely not being
> compatible with the real systemctl
> - handling of the return code from system()

Yes, i think this is correct. I will fill an additional bug report for
the systemctl package, which is the root cause of the problem. The bug
reported here just gave some additional headaches while searching the
real problem.

Thanks,
Sascha