Your message dated Tue, 25 Jan 2022 20:26:37 +0100
with message-id <[email protected]>
and subject line Re: Bug#1004339: /usr/bin/systemctl: `systemctl start --user 
--wait` fails with "Failed to connect to bus: No such file or directory"
has caused the Debian Bug report #1004339,
regarding /usr/bin/systemctl: `systemctl start --user --wait` fails with 
"Failed to connect to bus: No such file or directory"
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
1004339: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004339
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: systemd
Version: 250.3-1
Severity: normal
File: /usr/bin/systemctl

Dear Maintainer,

According to the systemctl.1 man page, it should be possible to specify
`--wait` to systemctl commands that will start units, to have the
systemctl command block until the units terminate again.  This seems to
work as expected for system units, but not for user units.

The attached short script provides a simple test case: given appropriate
ssh configuration, when run with `sudo bash test.sh` it will create a
new user called "test" with a simple example service template unit, then
log in through using ssh to start that unit twice, once without
`--wait`, and once with.  Expected behaviour is for this script to
start both unit instances, with the second one sleeping before the
script finishes.  Actual behaviour is that the first unit starts as
expected, but the second unit is never started, and the attempt gives a
return code of 1 and the following error printed to the terminal:

    Failed to connect to bus: No such file or directory

As I say, the `--wait` function works as expected for system units; it's
only with user units that it seems to fail.

Kind regards,

Adam

-- Package-specific info:

-- System Information:
Debian Release: 11.2
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-10-cloud-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd depends on:
ii  adduser          3.118
ii  libacl1          2.2.53-10
ii  libapparmor1     2.13.6-10
ii  libaudit1        1:3.0-2
ii  libblkid1        2.36.1-8
ii  libc6            2.33-3
ii  libcap2          1:2.44-1
ii  libcrypt1        1:4.4.18-4
ii  libcryptsetup12  2:2.4.3-1
ii  libfdisk1        2.36.1-8
ii  libgcrypt20      1.9.4-5
ii  libgnutls30      3.7.2-5
ii  libgpg-error0    1.38-2
ii  libip4tc2        1.8.7-1
ii  libkmod2         28-1
ii  liblz4-1         1.9.3-2
ii  liblzma5         5.2.5-2
ii  libmount1        2.36.1-8
ii  libpam0g         1.4.0-9+deb11u1
ii  libseccomp2      2.5.1-1+deb11u1
ii  libselinux1      3.1-3
ii  libsystemd0      250.3-1
ii  libzstd1         1.4.8+dfsg-2.1
ii  mount            2.36.1-8
ii  util-linux       2.36.1-8

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]   1.12.20-2
ii  systemd-timesyncd [time-daemon]  250.3-1

Versions of packages systemd suggests:
ii  libfido2-1            1.6.0-2
pn  libtss2-esys-3.0.2-0  <none>
pn  libtss2-mu0           <none>
pn  libtss2-rc0           <none>
pn  policykit-1           <none>
pn  systemd-container     <none>

Versions of packages systemd is related to:
pn  dracut           <none>
ii  initramfs-tools  0.140
pn  libnss-systemd   <none>
ii  libpam-systemd   250.3-1
ii  udev             247.3-6

-- no debconf information
set -eu
useradd test
mkdir -p ~test/.config/systemd/user
cat <<'EOF' >~test/.config/systemd/user/[email protected]
[Service]
ExecStart=sleep %I
EOF
mkdir -p ~test/.ssh
cp ~/.ssh/id_rsa.pub ~test/.ssh/authorized_keys
chown -R test:test ~test
ssh test@localhost 'systemctl --user start [email protected]'
ssh test@localhost 'systemctl --user status [email protected]'
ssh test@localhost 'systemctl --user start --wait [email protected]' || echo 
"Error: rc=$?"
ssh test@localhost 'systemctl --user status [email protected]'

--- End Message ---
--- Begin Message ---
Control: tags -1 - moreinfo unreproducible

Am 25.01.22 um 19:12 schrieb Adam Dinwoodie:
On Tue, Jan 25, 2022 at 06:04:37PM +0100, Michael Biebl wrote:

Is dbus-user-session installed? Is libpam-systemd enabled?

That was it: I'm running a fairly minimal headless system, and didn't
have dbus-user-session installed.  After installing that package, my
reproduction script behaves as expected.

Mea culpa.  Thank you for the help!

No problem. Closing accordingly.

Btw, I've submitted
https://salsa.debian.org/systemd-team/systemd/-/merge_requests/142

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


--- End Message ---

Reply via email to