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

2022-04-21 Thread Sascha Herrmann 
Package: init-system-helpers
Version: 1.60
Severity: normal
X-Debbugs-Cc: sh-b...@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  

-- no debconf information

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

2022-04-21 Thread 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-b...@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



OpenPGP_signature
Description: OpenPGP digital signature

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

2022-04-21 Thread 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

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

2022-04-21 Thread Michael Biebl 

Am 21.04.22 um 18:37 schrieb 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.


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.


OpenPGP_signature
Description: OpenPGP digital signature

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

2022-04-22 Thread sh-bugs 



On Thu, 21 Apr 2022 19:08:26 +0200 Michael Biebl  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