• Redis installation error(s) on Debian SID

    From John Cassidy@21:1/5 to All on Sat Oct 12 12:10:01 2024
    Hello all,

    trying to install Redis on Debian SID, the install is failing with the following errors:

    apt install redis
    Installing:
    redis

    Installing dependencies:
    libjemalloc2 liblzf1 redis-server redis-tools

    Suggested packages:
    ruby-redis

    Summary:
    Upgrading: 0, Installing: 5, Removing: 0, Not Upgrading: 0
    Download size: 0 B / 1232 kB
    Space needed: 7350 kB / 276 GB available

    Continue? [Y/n]
    Selecting previously unselected package libjemalloc2:arm64.
    (Reading database ... 305245 files and directories currently installed.) Preparing to unpack .../libjemalloc2_5.3.0-2+b1_arm64.deb ...
    Unpacking libjemalloc2:arm64 (5.3.0-2+b1) ...
    Selecting previously unselected package liblzf1:arm64.
    Preparing to unpack .../liblzf1_3.6-4+b1_arm64.deb ...
    Unpacking liblzf1:arm64 (3.6-4+b1) ...
    Selecting previously unselected package redis-tools.
    Preparing to unpack .../redis-tools_5%3a7.0.15-2_arm64.deb ...
    Unpacking redis-tools (5:7.0.15-2) ...
    Selecting previously unselected package redis-server.
    Preparing to unpack .../redis-server_5%3a7.0.15-2_arm64.deb ...
    Unpacking redis-server (5:7.0.15-2) ...
    Selecting previously unselected package redis.
    Preparing to unpack .../redis_5%3a7.0.15-2_all.deb ...
    Unpacking redis (5:7.0.15-2) ...
    Setting up libjemalloc2:arm64 (5.3.0-2+b1) ...
    Setting up liblzf1:arm64 (3.6-4+b1) ...
    Setting up redis-tools (5:7.0.15-2) ...
    Setting up redis-server (5:7.0.15-2) ...
    Created symlink '/etc/systemd/system/redis.service' → '/usr/lib/systemd/system/redis-server.service'.
    Created symlink '/etc/systemd/system/multi-user.target.wants/redis-server.service' → '/usr/lib/systemd/system/redis-server.service'.
    Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 148.
    Setting up redis (5:7.0.15-2) ...
    Processing triggers for man-db (2.13.0-1) ...
    Processing triggers for libc-bin (2.40-3) ...

    Has anyone experienced this situation before.

    If I remember correctly, another installlation of REDIS installed
    correctly on Bookworm.

    Any pointers/tips much appreciated

    Regards

    John Cassidy
    <html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 11pt; font-family: Arial,Helvetica,sans-serif'>
    <p>Hello all,</p>
    <p>trying to install Redis on Debian SID, the install is failing with the following errors:</p>
    <p>apt install redis<br />Installing: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;<br />&nbsp; redis</p>
    <p>Installing dependencies:<br />&nbsp; libjemalloc2 &nbsp;liblzf1 &nbsp;redis-server &nbsp;redis-tools</p>
    <p>Suggested packages:<br />&nbsp; ruby-redis</p>
    <p>Summary:<br />&nbsp; Upgrading: 0, Installing: 5, Removing: 0, Not Upgrading: 0<br />&nbsp; Download size: 0 B / 1232 kB<br />&nbsp; Space needed: 7350 kB / 276 GB available</p>
    <p>Continue? [Y/n]&nbsp;<br />Selecting previously unselected package libjemalloc2:arm64.<br />(Reading database ... 305245 files and directories currently installed.)<br />Preparing to unpack .../libjemalloc2_5.3.0-2+b1_arm64.deb ...<br />Unpacking
    libjemalloc2:arm64 (5.3.0-2+b1) ...<br />Selecting previously unselected package liblzf1:arm64.<br />Preparing to unpack .../liblzf1_3.6-4+b1_arm64.deb ...<br />Unpacking liblzf1:arm64 (3.6-4+b1) ...<br />Selecting previously unselected package redis-
    tools.<br />Preparing to unpack .../redis-tools_5%3a7.0.15-2_arm64.deb ...<br />Unpacking redis-tools (5:7.0.15-2) ...<br />Selecting previously unselected package redis-server.<br />Preparing to unpack .../redis-server_5%3a7.0.15-2_arm64.deb ...<br />
    Unpacking redis-server (5:7.0.15-2) ...<br />Selecting previously unselected package redis.<br />Preparing to unpack .../redis_5%3a7.0.15-2_all.deb ...<br />Unpacking redis (5:7.0.15-2) ...<br />Setting up libjemalloc2:arm64 (5.3.0-2+b1) ...<br />Setting
    up liblzf1:arm64 (3.6-4+b1) ...<br />Setting up redis-tools (5:7.0.15-2) ...<br />Setting up redis-server (5:7.0.15-2) ...<br />Created symlink '/etc/systemd/system/redis.service' &rarr; '/usr/lib/systemd/system/redis-server.service'.<br />Created
    symlink '/etc/systemd/system/multi-user.target.wants/redis-server.service' &rarr; '/usr/lib/systemd/system/redis-server.service'.<br />Could not execute systemctl: &nbsp;at /usr/bin/deb-systemd-invoke line 148.<br />Setting up redis (5:7.0.15-2) ...<br />
    Processing triggers for man-db (2.13.0-1) ...<br />Processing triggers for libc-bin (2.40-3) ...</p>
    <p><br /></p>
    <p>Has anyone experienced this situation before.</p>
    <p>If I remember correctly, another installlation of REDIS installed correctly on Bookworm.</p>
    <p>Any pointers/tips much appreciated</p>
    <p><br /></p>
    <p>Regards</p>
    <div id="signature">
    <p><br /></p>
    <p><br /></p>
    <p>John Cassidy</p>
    <p><br /></p>
    </div>
    </body></html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Wooledge@21:1/5 to John Cassidy on Sat Oct 12 15:30:02 2024
    On Sat, Oct 12, 2024 at 11:42:22 +0200, John Cassidy wrote:
    Setting up redis-server (5:7.0.15-2) ...
    Created symlink '/etc/systemd/system/redis.service' → '/usr/lib/systemd/system/redis-server.service'.
    Created symlink '/etc/systemd/system/multi-user.target.wants/redis-server.service' → '/usr/lib/systemd/system/redis-server.service'.
    Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 148.

    That's a very strange and specific error message. Is your systemctl
    command missing, or has incorrect permissions or something?

    hobbit:~$ ls -l /usr/bin/systemctl
    -rwxr-xr-x 1 root root 1353368 Aug 25 13:35 /usr/bin/systemctl*

    Are you able to run it normally? Just "systemctl" with no arguments
    as a non-privileged user should give you a list of units, presented
    in a pager (try "q" to get out of it).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Schmitt@21:1/5 to John Cassidy on Sat Oct 12 15:50:01 2024
    Hi,

    John Cassidy wrote:
    Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 148.

    Greg Wooledge wrote:
    That's a very strange and specific error message. Is your systemctl
    command missing, or has incorrect permissions or something?

    I rather guess that it is due to the perl thingies

    @instance_args, $action, @start_unit

    in

    system('systemctl', '--quiet', @instance_args, $action, @start_units) == 0 or die("Could not execute systemctl: $!");

    at
    https://sources.debian.org/src/init-system-helpers/1.67/script/deb-systemd-invoke/#L148

    One should make them visible and then re-try the Redis installation after possibly removing the debris of the nearly completed installation.
    We'd need a perl programmer to tell the exact command to insert before
    line 148 to make the systemctl command parameters visible before the
    execution attempt. Something like
    print STDERR "systemctl --quiet, @instance_args, $action, @start_units\n";


    The problem seems not uncommon:
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010893
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076530


    Have a nice day :)

    Thomas

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael =?utf-8?B?S2rDtnJsaW5n?=@21:1/5 to All on Sat Oct 12 16:10:01 2024
    On 12 Oct 2024 11:42 +0200, from [email protected] (John Cassidy):
    trying to install Redis on Debian SID, the install is failing with the following errors:

    apt install redis
    /snip/
    Setting up redis-server (5:7.0.15-2) ...
    Created symlink '/etc/systemd/system/redis.service' → '/usr/lib/systemd/system/redis-server.service'.
    Created symlink '/etc/systemd/system/multi-user.target.wants/redis-server.service' → '/usr/lib/systemd/system/redis-server.service'.
    Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 148. Setting up redis (5:7.0.15-2) ...

    For what little it might be worth, I am unable to reproduce this. I
    installed a fresh Debian 12 VM based on my template [1] (basically the
    standard and ssh-server tasks only), upgraded that directly to sid as
    of just now, and then ran `apt install redis`. It installed cleanly.

    The only possibly significant difference I can see is that I'm running
    on amd64 whereas your attempt was on arm64; but I honestly fail to see
    why such a difference would manifest itself in the kind of error you
    got.


    [1]: https://michael.kjorling.se/debian-12-bookworm-preseed/

    --
    Michael Kjörling 🔗 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”


    # apt install redis
    The following packages were automatically installed and are no longer required:
    libcbor0.8 libpython3.11-stdlib python3-httplib2
    libcurl3-gnutls librtmp1 python3-packaging
    libcurl4t64 libsasl2-2 python3-pycurl
    libfuse2 libsasl2-modules python3-pyparsing
    libldap-2.5-0 libsasl2-modules-db python3-pysimplesoap
    libldap-common libssh2-1t64 python3-six
    libperl5.36 linux-image-6.1.0-9-amd64 python3.11
    libpython3.11-minimal perl-modules-5.36 python3.11-minimal
    Use 'apt autoremove' to remove them.

    Installing:
    redis

    Installing dependencies:
    liblzf1 redis-server redis-tools

    Suggested packages:
    ruby-redis

    Summary:
    Upgrading: 0, Installing: 4, Removing: 0, Not Upgrading: 0
    Download size: 1,100 kB
    Space needed: 6,338 kB / 1,711 MB available

    Continue? [Y/n]
    Get:1 http://ftp.se.debian.org/debian sid/main amd64 liblzf1 amd64 3.6-4+b1 [10.4 kB]
    Get:2 http://ftp.se.debian.org/debian sid/main amd64 redis-tools amd64 5:7.0.15-2 [992 kB]
    Get:3 http://ftp.se.debian.org/debian sid/main amd64 redis-server amd64 5:7.0.15-2 [72.6 kB]
    Get:4 http://ftp.se.debian.org/debian sid/main amd64 redis all 5:7.0.15-2 [24.7 kB]
    Fetched 1,100 kB in 1s (2,098 kB/s)
    Selecting previously unselected package liblzf1:amd64.
    (Reading database ... 41616 files and directories currently installed.) Preparing to unpack .../liblzf1_3.6-4+b1_amd64.deb ...
    Unpacking liblzf1:amd64 (3.6-4+b1) ...
    Selecting previously unselected package redis-tools.
    Preparing to unpack .../redis-tools_5%3a7.0.15-2_amd64.deb ...
    Unpacking redis-tools (5:7.0.15-2) ...
    Selecting previously unselected package redis-server.
    Preparing to unpack .../redis-server_5%3a7.0.15-2_amd64.deb ...
    Unpacking redis-server (5:7.0.15-2) ...
    Selecting previously unselected package redis.
    Preparing to unpack .../redis_5%3a7.0.15-2_all.deb ...
    Unpacking redis (5:7.0.15-2) ...
    Setting up liblzf1:amd64 (3.6-4+b1) ...
    Setting up redis-tools (5:7.0.15-2) ...
    Setting up redis-server (5:7.0.15-2) ...
    Created symlink '/etc/systemd/system/redis.service' → '/usr/lib/systemd/system/redis-server.service'.
    Created symlink '/etc/systemd/system/multi-user.target.wants/redis-server.service' → '/usr/lib/systemd/system/redis-server.service'.
    Setting up redis (5:7.0.15-2) ...
    Processing triggers for man-db (2.13.0-1) ...
    Processing triggers for libc-bin (2.40-3) ...
    #

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [email protected]@21:1/5 to Thomas Schmitt on Sat Oct 12 19:10:01 2024
    "Thomas Schmitt" <[email protected]> wrote:
    Hi,

    John Cassidy wrote:
    Could not execute systemctl: at /usr/bin/deb-systemd-invoke line
    148.

    Greg Wooledge wrote:
    That's a very strange and specific error message. Is your systemctl command missing, or has incorrect permissions or something?

    I rather guess that it is due to the perl thingies

    @instance_args, $action, @start_unit

    in

    system('systemctl', '--quiet', @instance_args, $action,
    @start_units) == 0 or die("Could not execute systemctl: $!");

    But the error says that it could not execute systemctl, which suggests
    to me some specific problem with that binary rather than a problem with
    its args.

    However it won't do any harm to print the args as you suggest. You
    could use "warn" instead of "print STDERR".

    at
    https://sources.debian.org/src/init-system-helpers/1.67/script/deb-systemd-invoke/#L148

    One should make them visible and then re-try the Redis installation
    after possibly removing the debris of the nearly completed
    installation. We'd need a perl programmer to tell the exact command
    to insert before line 148 to make the systemctl command parameters
    visible before the execution attempt. Something like
    print STDERR "systemctl --quiet, @instance_args, $action,
    @start_units\n";


    The problem seems not uncommon:
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010893
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076530


    Have a nice day :)

    Thomas


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [email protected]@21:1/5 to [email protected] on Sat Oct 12 19:20:01 2024
    [email protected] wrote:
    "Thomas Schmitt" <[email protected]> wrote:
    Hi,

    John Cassidy wrote:
    Could not execute systemctl: at /usr/bin/deb-systemd-invoke
    line 148.

    Greg Wooledge wrote:
    That's a very strange and specific error message. Is your
    systemctl command missing, or has incorrect permissions or
    something?

    I rather guess that it is due to the perl thingies

    @instance_args, $action, @start_unit

    in

    system('systemctl', '--quiet', @instance_args, $action,
    @start_units) == 0 or die("Could not execute systemctl: $!");

    But the error says that it could not execute systemctl, which suggests
    to me some specific problem with that binary rather than a problem
    with its args.

    Actually, looking at https://perldoc.perl.org/functions/system suggests
    that the first and most important thing to print out is the value of $?
    rather than $!

    However it won't do any harm to print the args as you suggest. You
    could use "warn" instead of "print STDERR".

    at
    https://sources.debian.org/src/init-system-helpers/1.67/script/deb-systemd-invoke/#L148

    One should make them visible and then re-try the Redis installation
    after possibly removing the debris of the nearly completed
    installation. We'd need a perl programmer to tell the exact command
    to insert before line 148 to make the systemctl command parameters
    visible before the execution attempt. Something like
    print STDERR "systemctl --quiet, @instance_args, $action, @start_units\n";


    The problem seems not uncommon:
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010893
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076530


    Have a nice day :)

    Thomas



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Schmitt@21:1/5 to John Cassidy on Sat Oct 12 20:20:01 2024
    Hi,

    John Cassidy wrote:
    Could not execute systemctl: at /usr/bin/deb-systemd-invoke line
    148.

    i wrote:
    system('systemctl', '--quiet', @instance_args, $action, @start_units) == 0 or die("Could not execute systemctl: $!");
    https://sources.debian.org/src/init-system-helpers/1.67/script/deb-systemd-i
    nvoke/#L148

    [email protected] wrote:
    But the error says that it could not execute systemctl, which suggests
    to me some specific problem with that binary rather than a problem with
    its args.

    Well, if perl is not more awkward than i believe anyways, then the
    message is emitted if the run of program systemctl fails.
    The reasons for such a failure are manifold. From botched installation
    to lack of disk space ...

    The message text is obviously somewhat misleading.
    (I imagine a pressured perl programmer who has to invent a comprehensive
    error message and thinks "Let them look up the code on their own".
    So the users get shown the script name and the line number.)


    Have a nice day :)

    Thomas

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Karl Vogel@21:1/5 to All on Sun Oct 13 04:10:01 2024
    In previous messages:

    system('systemctl', '--quiet', [...] , @start_units) == 0
    or die("Could not execute systemctl: $!");

    Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 148.

    See the ":" followed by two spaces? Unlike systemctl, well-behaved
    programs set "errno" when they puke, and that setting is turned into
    a more-or-less useful error message like "Permission denied".
    "$!" would have held that message.

    I would try removing "'--quiet'," from the system() call -- maybe
    systemctl didn't get something it needed in the argument list.

    I'd also use the full path ('/usr/bin/systemctl' or whatever) because
    otherwise you're trusting $PATH to be set correctly.

    On Sat 12 Oct 2024 at 14:10:20 (-0400), Thomas Schmitt wrote:

    Well, if perl is not more awkward than i believe anyways, then the
    message is emitted if the run of program systemctl fails. The reasons
    for such a failure are manifold, from botched installation to lack of
    disk space...

    Exactly right, and we shouldn't have to guess.

    I imagine a pressured perl programmer who has to invent a
    comprehensive error message and thinks "Let them look up the code
    on their own". So the users get shown the script name and the line
    number.

    I avoid using system() because it's bitten me in the ass before; any
    metacharacters in any argument cause the whole thing to be passed to a
    shell, which can result in all sorts of entertainment. If I ever have
    to use it in a perl script, I make a safe wrapper. I've attached a
    small example.

    --
    Karl Vogel I don't speak for anyone but myself

    Manhunt Underway After Lubed-Up Diddy Slips Out From Between Prison Bars
    --Babylon Bee, 20 Sep 2024

    Perl script cleverly called "tst":

    1 #!/usr/bin/perl
    2 #<tst: try a wrapper around system().
    3
    4 use Modern::Perl;
    5 use subs qw/safesys/;
    6
    7 my @instance_args = ('i1', 'i2');
    8 my $action = 'do-something';
    9 my @start_units = ('st1', 'st2', 'st3');
    10
    11 print "Calling safesys, should work...\n";
    12 safesys('/bin/ls', '-lF', "$0");
    13
    14 print "\n...calling safesys again...\n";
    15 safesys('systemctl', '--quiet', @instance_args, $action, @start_units);
    16
    17 print "...should not get here\n";
    18 exit(0);
    19
    20 # -------------------------------------------------------------------
    21 # safesys: run a command using system, view any unexpected results.
    22 sub safesys {
    23 unless (system(@_) == 0) {
    24 my ($package, $filename, $line) = caller;
    25
    26 printf " PACKAGE: %s\n FILE: %s\n LINE: %d\n",
    27 $package, $filename, $line;
    28
    29 print "system() failed with arguments:\n ";
    30 print "[$_] " foreach @_;
    31 print "\n";
    32
    33 if ($? == -1) {
    34 print "failed to execute: $!\n";
    35 }
    36 elsif ($? & 127) {
    37 printf "child died with signal %d, %s coredump\n",
    38 ($? & 127), ($? & 128) ? 'with' : 'without';
    39 }
    40 else {
    41 printf "child exited with value %d\n", $? >> 8;
    42 }
    43
    44 exit($?);
    45 }
    46 }

    When I run it, the first call succeeds in passing its own name to "ls".

    I don't have systemctl installed on my machine, so the second call fails
    at line 23. I use "caller" to see where the problem actually occurred
    (line 15) and what args were passed to systemctl:

    me% ./tst
    Calling safesys, should work...
    -rwxr-xr-x 1 vogelke mis 1242 Oct 12 21:37 ./tst*

    ...calling safesys again...
    Can't exec "systemctl": No such file or directory at ./tst line 23.
    PACKAGE: main
    FILE: ./tst
    LINE: 15
    system() failed with arguments:
    [systemctl] [--quiet] [i1] [i2] [do-something] [st1] [st2] [st3]
    failed to execute: No such file or directory

    As you can see, the script never makes it to line 17.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Wooledge@21:1/5 to Karl Vogel on Sun Oct 13 04:30:01 2024
    On Sat, Oct 12, 2024 at 21:43:39 -0400, Karl Vogel wrote:
    In previous messages:

    system('systemctl', '--quiet', [...] , @start_units) == 0
    or die("Could not execute systemctl: $!");

    Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 148.

    See the ":" followed by two spaces? Unlike systemctl, well-behaved
    programs set "errno" when they puke, and that setting is turned into
    a more-or-less useful error message like "Permission denied".
    "$!" would have held that message.

    I don't think this is correct. A *function* can set errno (a global
    variable in C), in addition to returning a value. A process can't,
    unless there has been some major change to the Unix process model that
    I've missed.

    A failing process can return an exit status greater than 0 to indicate
    that something has gone awry, but that's it. There's no other mechanism available (that I know of) to pass information back to the parent
    process. The closest thing would be that the parent can detect whether
    the child was killed by a signal, which is not relevant here.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [email protected]@21:1/5 to Greg Wooledge on Sun Oct 13 07:50:01 2024
    On Sat, Oct 12, 2024 at 10:23:00PM -0400, Greg Wooledge wrote:
    On Sat, Oct 12, 2024 at 21:43:39 -0400, Karl Vogel wrote:
    In previous messages:

    system('systemctl', '--quiet', [...] , @start_units) == 0
    or die("Could not execute systemctl: $!");

    Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 148.

    See the ":" followed by two spaces? Unlike systemctl, well-behaved
    programs set "errno" when they puke, and that setting is turned into
    a more-or-less useful error message like "Permission denied".
    "$!" would have held that message.

    I don't think this is correct. A *function* can set errno (a global
    variable in C), in addition to returning a value. A process can't,
    unless there has been some major change to the Unix process model that
    I've missed.

    That's correct: in Perl, $! is the ERRNO of the last /failed/ system call (think, e.g. open). What the OP (original prorammer? ;-) wanted to say
    here is $?, which would be the "child exit status" -- i.e. what systemctl
    wants to tell us, if anything.

    The errno is fine (more precisely: wasn't touched, so it stayed at 0 if
    it was before) since the fork() underlying system(...) actually succeeded.

    See man perlvar(1) for the gory details (since it's big, search for ERRNO
    or CHILD_ERROR there, respectively).

    Cheers
    --
    t

    -----BEGIN PGP SIGNATURE-----

    iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZwteOwAKCRAFyCz1etHa Rg7uAJ0Rbc6KxCt9zzHLTeWNdbHPDvNFbgCfR8wOk1f0QE08rKLEth9qkjsX97I=
    =p+Yr
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Karl Vogel@21:1/5 to I mistakenly on Sun Oct 13 08:30:01 2024
    On Sat, Oct 12, 2024 at 21:43:39 -0400, I mistakenly wrote:
    See the ":" followed by two spaces? Unlike systemctl, well-behaved
    programs set "errno" when they puke, and that setting is turned into
    a more-or-less useful error message like "Permission denied".
    "$!" would have held that message.

    On Sat 12 Oct 2024 at 22:23:31 (-0400), Greg Wooledge replied:
    I don't think this is correct. A *function* can set errno (a global
    variable in C), in addition to returning a value. A process can't,
    unless there has been some major change to the Unix process model that
    I've missed.

    You're right, keyboard in motion before brain in gear. Since I don't
    have systemctl installed, the system() *function* failed when it tried to
    exec a non-existent program and correctly set "$!" to "No such file
    or directory".

    If I call 'system("/bin/mkdir", "/etc/something")' as myself, the
    /bin/mkdir *process* handles errno and prints "Permission denied".
    All system() sees is a non-0 exit code.

    Removing the --quiet flag and using something like safesys() would:

    * let systemctl write something (hopefully an error message),
    * show exactly what arguments are being passed to it, and
    * show its exit value.

    --
    Karl Vogel I don't speak for anyone but myself

    In [the movie] "Seven", I put it in my contract:
    The wife's head stays in the box.
    --Brad Pitt on early contract negotiations

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [email protected]@21:1/5 to Karl Vogel on Sun Oct 13 12:30:01 2024
    Karl Vogel <[email protected]> wrote:

    Removing the --quiet flag and using something like safesys() would:

    * let systemctl write something (hopefully an error message),
    * show exactly what arguments are being passed to it, and
    * show its exit value.

    Your safesys includes basically exactly the code suggested in perldoc
    system so that's good.

    I believe systemctl prints errors regardless of the presence of --quiet
    so removing it may not be necessary, but can't do any harm.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)