Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Andrei Borzenkov]

On 08.12.2023 23:53, Mantas Mikulėnas wrote:
...



Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Will mount
/run/user/1001 owned by 1001:118

Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Mounting tmpfs
(tmpfs) on /run/user/1001 (MS_NOSUID|MS_NODEV
"mode=0700,uid=1001,gid=118,size=99426304,nr_inodes=24274")...

Dec 08 17:33:29 host systemd[1]: Finished User Runtime Directory
/run/user/1001.

Dec 08 17:33:29 host systemd[1]: Starting User Manager for UID 1001...

Dec 08 17:33:29 host systemd[36280]: systemd 254.7-2-g9edc143 running in
user mode for user 1001/ida. (-PAM -AUDIT -SELINUX -APPARMOR +IMA -SMACK
+SECCOMP +GCRYPT +GNUTLS +OPENSSL -ACL +BLKID +CURL -ELFUTILS -FIDO2 -IDN2
-IDN -IPTC +KMOD -LIBCRYPTSETUP +LIBFDISK -PCRE2 -PWQUALITY -P11KIT
-QRENCODE -TPM2 +BZIP2 -LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON -UTMP
-SYSVINIT default-hierarchy=unified)

Dec 08 17:33:29 host systemd[36280]: Failed to create
'/run/user/1001/systemd/inaccessible', ignoring: Permission denied

Dec 08 17:33:29 host systemd[36280]: Failed to create
'/run/user/1001/systemd/inaccessible/reg', ignoring: Permission denied

Dec 08 17:33:29 host systemd[36280]: Failed to create
'/run/user/1001/systemd/inaccessible/dir', ignoring: Permission denied

Dec 08 17:33:29 host systemd[36280]: Failed to create
'/run/user/1001/systemd/inaccessible/fifo', ignoring: Permission denied

Dec 08 17:33:29 host systemd[36280]: Failed to create
'/run/user/1001/systemd/inaccessible/sock', ignoring: Permission denied

Dec 08 17:33:29 host systemd[36280]: Failed to create
'/run/user/1001/systemd/inaccessible/chr', ignoring: Permission denied

Dec 08 17:33:29 host systemd[36280]: Failed to create
'/run/user/1001/systemd/inaccessible/blk', ignoring: Permission denied



What's the ownership of /run/user/1001 and /run/user/1001/systemd after all
of this?

Are you rebooting between tests or just manually starting it?

My current guess is that due to the earlier `systemctl set-environment`,
some *other* thing that's running as root inherited the /run/user/1001 path
and created root-owned directories there? That's the issue with setting
global environment, it needs to be unset afterwards...



"Permission denied" sounds like something LSM related (AppArmor, 
SELinux, ...)

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Mantas Mikulėnas]

On Fri, Dec 8, 2023 at 6:53 PM Christopher Wong 
wrote:

> Hi Mantas,
>
>
>
> I have from your suggestion done the following:
>
>
>
> Putting the below in user@.service
>
>
>
> [Service]
>
> ...
>
> Environment=XDG_RUNTIME_DIR=/run/user/%i
>
> Environment=SYSTEMD_LOG_LEVEL=debug
>
>
>
> Putting the below in user-runtime-dir@.service
>
>
>
> [Service]
>
> ...
>
> Environment=SYSTEMD_LOG_LEVEL=debug
>
>
>
> Then I have disabled the global set-log-level debug (if this is also
> required, please let me know).
>

Unlike set-environment that's not global, it only affects pid1.



> What I can see from the logs is that user-runtime-dir@1001.service seems
> to be started and mount /run/user/1001, but addition creation of directory
> under this mount is getting permission denied.
>
>
>
> Dec 08 17:33:29 host systemd[1]: Created slice User Slice of UID 1001.
>
> Dec 08 17:33:29 host systemd[1]: Starting User Runtime Directory
> /run/user/1001...
>
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Bus n/a: changing
> state UNSET -> OPENING
>
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: sd-bus: starting bus
> by connecting to /run/dbus/system_bus_socket...
>
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Bus n/a: changing
> state OPENING -> AUTHENTICATING
>
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Bus n/a: changing
> state AUTHENTICATING -> HELLO
>
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Sent message
> type=method_call sender=n/a destination=org.freedesktop.DBus
> path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello
> cookie=1 reply_cookie=0 signature=n/a error-name=n/a error-message=n/a
>
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Got message
> type=method_return sender=org.freedesktop.DBus destination=:1.2536 path=n/a
> interface=n/a member=n/a  cookie=1 reply_cookie=1 signature=s
> error-name=n/a error-message=n/a
>
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Bus n/a: changing
> state HELLO -> RUNNING
>
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Sent message
> type=method_call sender=n/a destination=org.freedesktop.login1
> path=/org/freedesktop/login1 interface=org.freedesktop.DBus.Properties
> member=Get cookie=2 reply_cookie=0 signature=ss error-name=n/a
> error-message=n/a
>
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Got message
> type=method_return sender=:1.323 destination=:1.2536 path=n/a interface=n/a
> member=n/a  cookie=15 reply_cookie=2 signature=v error-name=n/a
> error-message=n/a
>
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Sent message
> type=method_call sender=n/a destination=org.freedesktop.login1
> path=/org/freedesktop/login1 interface=org.freedesktop.DBus.Properties
> member=Get cookie=3 reply_cookie=0 signature=ss error-name=n/a
> error-message=n/a
>
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Got message
> type=method_return sender=:1.323 destination=:1.2536 path=n/a interface=n/a
> member=n/a  cookie=16 reply_cookie=3 signature=v error-name=n/a
> error-message=n/a
>
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Bus n/a: changing
> state RUNNING -> CLOSED
>
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Will mount
> /run/user/1001 owned by 1001:118
>
> Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Mounting tmpfs
> (tmpfs) on /run/user/1001 (MS_NOSUID|MS_NODEV
> "mode=0700,uid=1001,gid=118,size=99426304,nr_inodes=24274")...
>
> Dec 08 17:33:29 host systemd[1]: Finished User Runtime Directory
> /run/user/1001.
>
> Dec 08 17:33:29 host systemd[1]: Starting User Manager for UID 1001...
>
> Dec 08 17:33:29 host systemd[36280]: systemd 254.7-2-g9edc143 running in
> user mode for user 1001/ida. (-PAM -AUDIT -SELINUX -APPARMOR +IMA -SMACK
> +SECCOMP +GCRYPT +GNUTLS +OPENSSL -ACL +BLKID +CURL -ELFUTILS -FIDO2 -IDN2
> -IDN -IPTC +KMOD -LIBCRYPTSETUP +LIBFDISK -PCRE2 -PWQUALITY -P11KIT
> -QRENCODE -TPM2 +BZIP2 -LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON -UTMP
> -SYSVINIT default-hierarchy=unified)
>
> Dec 08 17:33:29 host systemd[36280]: Failed to create
> '/run/user/1001/systemd/inaccessible', ignoring: Permission denied
>
> Dec 08 17:33:29 host systemd[36280]: Failed to create
> '/run/user/1001/systemd/inaccessible/reg', ignoring: Permission denied
>
> Dec 08 17:33:29 host systemd[36280]: Failed to create
> '/run/user/1001/systemd/inaccessible/dir', ignoring: Permission denied
>
> Dec 08 17:33:29 host systemd[36280]: Failed to create
> '/run/user/1001/systemd/inaccessible/fifo', ignoring: Permission denied
>
> Dec 08 17:33:29 host systemd[36280]: Failed to create
> '/run/user/1001/systemd/inaccessible/sock', ignoring: Permission denied
>
> Dec 08 17:33:29 host systemd[36280]: Failed to create
> '/run/user/1001/systemd/inaccessible/chr', ignoring: Permission denied
>
> Dec 08 17:33:29 host systemd[36280]: Failed to create
> '/run/user/1001/systemd/inaccessible/blk', ignoring: Permission denied
>

What's the ownership of 

[RFC] initoverlayfs - a scalable initial filesystem

[Eric Curtin]

We have been working on a new initial filesystem called initoverlayfs.
It is a new filesystem that provides a more scalable approach to
initial filesystems as opposed to just using initrds. We are writing
this RFC to the systemd and dracut mailing lists (feel free to forward
to UAPI group also) because although this solution works without
changing the code in these projects, it operates in the same area as
systemd, udev, dracut, etc. and uses these tools.

Brief context:
--

initoverlayfs by default uses transient overlays rather than tmpfs to
create throwaway filesystems early in the boot sequence.

Why?

An initramfs has to be decompressed and copied to a tmpfs up front
before it can be used. This results in a situation where you end up
paying for every byte in an initrd in boot performance, even the ones
you don't use in a given boot.

This leads to a fear of using languages that result in larger binaries
sizes early boot, reusing libraries, etc. In some cases, reimplemented
minified versions of software components present in the rootfs are
used.

Alternatively, initoverlayfs uses erofs (with compression) and
overlayfs to achieve this, so you only pay for the bytes you actually
use.

There is also increased pressure from certain industries like
automotive, to start essential services in a boot sequence early.

Requirements:
-

An init system
An initramfs building tool
A device manager
overlayfs

Nothing that you wouldn't find in most Linux distributions today.

Design:
---

Here is the boot sequence with initoverlayfs integrated, the
mini-initramfs contains just enough to get storage drivers loaded and
storage devices initialized. storage-init is a process that is not
designed to replace init, it does just enough to initialize storage
(performs a targeted udev trigger on storage), switches to
initoverlayfs as root and then executes init.

```
fw -> bootloader -> kernel -> mini-initramfs -> initoverlayfs -> rootfs

fw -> bootloader -> kernel -> storage-init   -> init ->
```

Benefits:
-

Scalability: You can put less emphasis on keeping this initial
filesystem small as you will only pay for the bytes you read. This is
probably the bigger picture than raw performance in the next point.

Performance: As this minifies the initramfs to contain only the most
basic storage initialization tasks, linux userspace starts earlier
than it would using just initramfs alone. Leaving all the other
software that require early throwaway filesystems to be executed in
the initoverlayfs. In the case of a Raspberry Pi 4 with sd card, it
leads to systemd starting ~300ms faster and in the case of a Raspberry
Pi 4 with NVMe SSD drive over USB it leads to systemd starting ~500ms
faster. There are some devices that by starting Linux userspace early,
you can expose a slowly initializing storage driver, leading to a
slower boot as with just an initramfs you mask this slow driver by
spending this time on decompression and copying. But a computer is
only as fast as it's slowest component, so if you care about super
fast boots, you need to optimize your storage drivers.

Flexibility: It is now easier to consider using fatter languages like
Rust, etc. Using libraries like graphics libraries, camera libraries,
libevent, glib, C++, etc. early boot can be considered. As you don't
have to decompress and copy this data upfront. This leads to easier to
maintain initrd software also, with more consolidation between rootfs
impelmentations and initial filesystem implementations of components.

Changes required in other projects:
---

There are no major changes required in other projects. Tools like
systemd-analyze might need to be updated to recognize this boot
sequence more accurately, because it has no awareness of
initoverlayfs.

Future plans:
-

We intend to propose this to Fedora, CentOS Stream, ostree and
non-ostree variants as we continue this project.

Feel free to try:
-

It should work on most standard 3 partition non-ostree Fedora and
CentOS 9 installs (note: CentOS 9 kernel does not support erofs
compression, so Fedora is a better playground today). It's still in
alpha/beta state I guess. Although I successfully dogfood this on my
laptop and we hard tried this on a couple of different pieces of
hardware and VMs... Maybe run this on a non-critical piece of hardware
or a VM for the next few weeks if you want to try :)

git repo:

https://github.com/containers/initoverlayfs

Also checkout the README.md, there are some graphs and other information there:

https://github.com/containers/initoverlayfs/blob/main/README.md

rpm available in copr:

dnf copr enable @centos-automotive-sig/next
dnf install initoverlayfs
initoverlayfs-install

Is mise le meas/Regards,

Eric Curtin

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Christopher Wong]

Hi Mantas,

I have from your suggestion done the following:

Putting the below in user@.service

[Service]
...
Environment=XDG_RUNTIME_DIR=/run/user/%i
Environment=SYSTEMD_LOG_LEVEL=debug

Putting the below in user-runtime-dir@.service

[Service]
...
Environment=SYSTEMD_LOG_LEVEL=debug

Then I have disabled the global set-log-level debug (if this is also required, 
please let me know). What I can see from the logs is that 
user-runtime-dir@1001.service seems to be 
started and mount /run/user/1001, but addition creation of directory under this 
mount is getting permission denied.

Dec 08 17:33:29 host systemd[1]: Created slice User Slice of UID 1001.
Dec 08 17:33:29 host systemd[1]: Starting User Runtime Directory 
/run/user/1001...
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Bus n/a: changing state 
UNSET -> OPENING
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: sd-bus: starting bus by 
connecting to /run/dbus/system_bus_socket...
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Bus n/a: changing state 
OPENING -> AUTHENTICATING
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Bus n/a: changing state 
AUTHENTICATING -> HELLO
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Sent message 
type=method_call sender=n/a destination=org.freedesktop.DBus 
path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 
reply_cookie=0 signature=n/a error-name=n/a error-message=n/a
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Got message 
type=method_return sender=org.freedesktop.DBus destination=:1.2536 path=n/a 
interface=n/a member=n/a  cookie=1 reply_cookie=1 signature=s error-name=n/a 
error-message=n/a
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Bus n/a: changing state 
HELLO -> RUNNING
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Sent message 
type=method_call sender=n/a destination=org.freedesktop.login1 
path=/org/freedesktop/login1 interface=org.freedesktop.DBus.Properties 
member=Get cookie=2 reply_cookie=0 signature=ss error-name=n/a error-message=n/a
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Got message 
type=method_return sender=:1.323 destination=:1.2536 path=n/a interface=n/a 
member=n/a  cookie=15 reply_cookie=2 signature=v error-name=n/a 
error-message=n/a
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Sent message 
type=method_call sender=n/a destination=org.freedesktop.login1 
path=/org/freedesktop/login1 interface=org.freedesktop.DBus.Properties 
member=Get cookie=3 reply_cookie=0 signature=ss error-name=n/a error-message=n/a
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Got message 
type=method_return sender=:1.323 destination=:1.2536 path=n/a interface=n/a 
member=n/a  cookie=16 reply_cookie=3 signature=v error-name=n/a 
error-message=n/a
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Bus n/a: changing state 
RUNNING -> CLOSED
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Will mount /run/user/1001 
owned by 1001:118
Dec 08 17:33:29 host systemd-user-runtime-dir[36278]: Mounting tmpfs (tmpfs) on 
/run/user/1001 (MS_NOSUID|MS_NODEV 
"mode=0700,uid=1001,gid=118,size=99426304,nr_inodes=24274")...
Dec 08 17:33:29 host systemd[1]: Finished User Runtime Directory /run/user/1001.
Dec 08 17:33:29 host systemd[1]: Starting User Manager for UID 1001...
Dec 08 17:33:29 host systemd[36280]: systemd 254.7-2-g9edc143 running in user 
mode for user 1001/ida. (-PAM -AUDIT -SELINUX -APPARMOR +IMA -SMACK +SECCOMP 
+GCRYPT +GNUTLS +OPENSSL -ACL +BLKID +CURL -ELFUTILS -FIDO2 -IDN2 -IDN -IPTC 
+KMOD -LIBCRYPTSETUP +LIBFDISK -PCRE2 -PWQUALITY -P11KIT -QRENCODE -TPM2 +BZIP2 
-LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON -UTMP -SYSVINIT 
default-hierarchy=unified)
Dec 08 17:33:29 host systemd[36280]: Failed to create 
'/run/user/1001/systemd/inaccessible', ignoring: Permission denied
Dec 08 17:33:29 host systemd[36280]: Failed to create 
'/run/user/1001/systemd/inaccessible/reg', ignoring: Permission denied
Dec 08 17:33:29 host systemd[36280]: Failed to create 
'/run/user/1001/systemd/inaccessible/dir', ignoring: Permission denied
Dec 08 17:33:29 host systemd[36280]: Failed to create 
'/run/user/1001/systemd/inaccessible/fifo', ignoring: Permission denied
Dec 08 17:33:29 host systemd[36280]: Failed to create 
'/run/user/1001/systemd/inaccessible/sock', ignoring: Permission denied
Dec 08 17:33:29 host systemd[36280]: Failed to create 
'/run/user/1001/systemd/inaccessible/chr', ignoring: Permission denied
Dec 08 17:33:29 host systemd[36280]: Failed to create 
'/run/user/1001/systemd/inaccessible/blk', ignoring: Permission denied
Dec 08 17:33:29 host systemd[36280]: Failed to create parent directory of 
/run/user/1001/systemd/propagate/.os-release-stage/os-release, ignoring: 
Permission denied
Dec 08 17:33:29 host systemd[36280]: Failed to copy os-release for propagation, 
ignoring: Permission denied
Dec 08 17:33:29 host systemd[36280]: Failed at setting rlimit 

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Mantas Mikulėnas]

On Fri, Dec 8, 2023, 12:22 Christopher Wong 
wrote:

> Hi Luca,
>
>
>
> Sorry, for late reply, below is a log with debug. This time I run with a
> user with higher UID, but the result is the same.
>
>
>
> root@host:~# systemd-analyze set-log-level debug
>
> root@host:~# systemctl set-environment XDG_RUNTIME_DIR="/run/user/1001"
>

I'd avoid doing that globally. If you really want to have a PAM-less
system, then edit the unit to set this through its Environment= instead.

root@host:~# systemctl start user@1001.service
>
> Job for user@1001.service failed because the control process exited with
> error code.
>
> See "systemctl status user@1001.service" and "journalctl -xeu
> user@1001.service" for details.
>
> root@host:~# journalctl -xeu user@1001.service
>
> Dec 08 09:35:53 host systemd[1]: /usr/lib/systemd/system/user@.service:19:
> Support for option PAMName= has been disabled at compile time and it is
> ignored
>
> Dec 08 09:35:53 host systemd[1]: user@1001.service: Trying to enqueue job
> user@1001.service/start/replace
>
> Dec 08 09:35:53 host systemd[1]: user@1001.service: Installed new job
> user@1001.service/start as 6724
>
> Dec 08 09:35:53 host systemd[1]: user@1001.service: Enqueued job
> user@1001.service/start as 6724
>
> Dec 08 09:35:53 host systemd[1]: user@1001.service: starting held back,
> waiting for: user-runtime-dir@1001.service
>
> Dec 08 09:35:54 host systemd[1]: user@1001.service: Will spawn child
> (service_enter_start): /usr/lib/systemd/systemd
>
> Dec 08 09:35:54 host systemd[1]: user@1001.service: Failed to set
> 'memory.zswap.max' attribute on
> '/user.slice/user-1001.slice/user@1001.service' to 'max': No such file or
> directory
>
> Dec 08 09:35:54 host systemd[1]: user@1001.service: Passing 0 fds to
> service
>
> Dec 08 09:35:54 host systemd[1]: user@1001.service: About to execute:
> /usr/lib/systemd/systemd --user
>
> Dec 08 09:35:54 host systemd[1]: user@1001.service: Forked
> /usr/lib/systemd/systemd as 6899
>
> Dec 08 09:35:54 host (systemd)[6899]: Found cgroup2 on /sys/fs/cgroup/,
> full unified hierarchy
>
> Dec 08 09:35:54 host systemd[1]: user@1001.service: Changed dead -> start
>
> Dec 08 09:35:54 host systemd[1]: Starting User Manager for UID 1001...
>
> Dec 08 09:35:54 host (systemd)[6899]: Bind-mounting / on
> /run/systemd/mount-rootfs (MS_BIND|MS_REC "")...
>
> Dec 08 09:35:54 host systemd[1]: user@1001.service: User lookup
> succeeded: uid=1001 gid=118
>
> Dec 08 09:35:54 host (systemd)[6899]: Applying namespace mount on
> /run/systemd/mount-rootfs/run/credentials
>
> Dec 08 09:35:54 host (systemd)[6899]: Bind-mounting
> /run/systemd/inaccessible/dir on /run/systemd/mount-rootfs/run/credentials
> (MS_BIND|MS_REC "")...
>
> Dec 08 09:35:54 host (systemd)[6899]: Successfully mounted
> /run/systemd/inaccessible/dir to /run/systemd/mount-rootfs/run/credentials
>
> Dec 08 09:35:54 host (systemd)[6899]: Applying namespace mount on
> /run/systemd/mount-rootfs/run/systemd/incoming
>
> Dec 08 09:35:54 host (systemd)[6899]: Followed source symlinks
> /run/systemd/propagate/user@1001.service →
> /run/systemd/propagate/user@1001.service.
>
> Dec 08 09:35:54 host (systemd)[6899]: Bind-mounting
> /run/systemd/propagate/user@1001.service on
> /run/systemd/mount-rootfs/run/systemd/incoming (MS_BIND "")...
>
> Dec 08 09:35:54 host (systemd)[6899]: Successfully mounted
> /run/systemd/propagate/user@1001.service to
> /run/systemd/mount-rootfs/run/systemd/incoming
>
> Dec 08 09:35:54 host (systemd)[6899]: Applying namespace mount on
> /run/systemd/mount-rootfs/sys
>
> Dec 08 09:35:54 host (systemd)[6899]: Failed to umount
> /run/systemd/mount-rootfs/sys, ignoring: Device or resource busy
>
> Dec 08 09:35:54 host (systemd)[6899]: Failed to umount
> /run/systemd/mount-rootfs/sys, ignoring: Device or resource busy
>
> Dec 08 09:35:54 host (systemd)[6899]: Failed to umount
> /run/systemd/mount-rootfs/sys, ignoring: Device or resource busy
>
> Dec 08 09:35:54 host (systemd)[6899]: Failed to umount
> /run/systemd/mount-rootfs/sys, ignoring: Device or resource busy
>
> Dec 08 09:35:54 host (systemd)[6899]: Failed to umount
> /run/systemd/mount-rootfs/sys, ignoring: Device or resource busy
>
> Dec 08 09:35:54 host (systemd)[6899]: Failed to umount
> /run/systemd/mount-rootfs/sys, ignoring: Device or resource busy
>
> Dec 08 09:35:54 host (systemd)[6899]: Failed to umount
> /run/systemd/mount-rootfs/sys, ignoring: Device or resource busy
>
> Dec 08 09:35:54 host (systemd)[6899]: Failed to umount
> /run/systemd/mount-rootfs/sys, ignoring: Device or resource busy
>
> Dec 08 09:35:54 host (systemd)[6899]: Mounting sysfs (sysfs) on
> /run/systemd/mount-rootfs/sys (MS_NOSUID|MS_NODEV|MS_NOEXEC "")...
>
> Dec 08 09:35:54 host (systemd)[6899]: user@1001.service: Executing:
> /usr/lib/systemd/systemd --user
>
> Dec 08 09:35:54 host systemd[6899]: Failed to copy os-release for
> propagation, ignoring: Permission denied
>
> Dec 08 09:35:54 host systemd[6899]: Failed to allocate manager object:
> 

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Lennart Poettering]

On Fr, 08.12.23 08:52, Christopher Wong (christopher.w...@axis.com) wrote:

> Hi Lennart,
>
> I know we are not using the pam_systemd. That is the reason we try
> to run the steps manually. It was possible to start the
> user@.service in systemd v253, but it fails now with v254 or
> later.

Well, that's not supported then. You need XDG_RUNTIME_DIR set up
properly, and that's what the PAM module gives you. If you turn off
the PAM module then you get to keep the pieces, you voided your
warranty.

Lennart

--
Lennart Poettering, Berlin

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Aki Ketolainen]

On 2023-12-07 23:03, Lennart Poettering wrote:


The 503 is a system user. So, just to try it out, I created a user,
which got the UID 1001. Using that UID gave me the same result as
the 503.


It's a bad idea to run user stuff as system user.

Lennart


Why's that?

Best regards,

Aki

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Christopher Wong]

Hi Lennart,

I know we are not using the pam_systemd. That is the reason we try to run the 
steps manually. It was possible to start the user@.service in systemd 
v253, but it fails now with v254 or later.

Best regards,
Christopher Wong



From: Lennart Poettering 
Date: Thursday, 7 December 2023 at 22:03
To: Christopher Wong 
Cc: systemd-devel@lists.freedesktop.org 
Subject: Re: [systemd-devel] Manual start of user@.service failed with 
permission denied
On Do, 07.12.23 18:29, Christopher Wong (christopher.w...@axis.com) wrote:

> Hi Lennart,
>
> We are doing the steps to start up a rootless docker. If I don’t set 
> XDG_RUNTIME_DIR then I will get the below error:
>
> systemd[1925]: Trying to run as user instance, but $XDG_RUNTIME_DIR
> is not set.

pam_systemd is responsible for setting this env var. Most likely you
are missing that from the PAM stack that is used by this user@.service
instance?

> The 503 is a system user. So, just to try it out, I created a user,
> which got the UID 1001. Using that UID gave me the same result as
> the 503.

It's a bad idea to run user stuff as system user.

Lennart

--
Lennart Poettering, Berlin

Re: [systemd-devel] Manual start of user@.service failed with permission denied

[Christopher Wong]

Hi Luca,

Sorry, for late reply, below is a log with debug. This time I run with a user 
with higher UID, but the result is the same.

root@host:~# systemd-analyze set-log-level debug
root@host:~# systemctl set-environment XDG_RUNTIME_DIR="/run/user/1001"
root@host:~# systemctl start user@1001.service
Job for user@1001.service failed because the control process exited with error 
code.
See "systemctl status user@1001.service" and "journalctl -xeu 
user@1001.service" for details.
root@host:~# journalctl -xeu user@1001.service
Dec 08 09:35:53 host systemd[1]: /usr/lib/systemd/system/user@.service:19: 
Support for option PAMName= has been disabled at compile time and it is ignored
Dec 08 09:35:53 host systemd[1]: user@1001.service: Trying to enqueue job 
user@1001.service/start/replace
Dec 08 09:35:53 host systemd[1]: user@1001.service: Installed new job 
user@1001.service/start as 6724
Dec 08 09:35:53 host systemd[1]: user@1001.service: Enqueued job 
user@1001.service/start as 6724
Dec 08 09:35:53 host systemd[1]: user@1001.service: starting held back, waiting 
for: user-runtime-dir@1001.service
Dec 08 09:35:54 host systemd[1]: user@1001.service: Will spawn child 
(service_enter_start): /usr/lib/systemd/systemd
Dec 08 09:35:54 host systemd[1]: user@1001.service: Failed to set 
'memory.zswap.max' attribute on '/user.slice/user-1001.slice/user@1001.service' 
to 'max': No such file or directory
Dec 08 09:35:54 host systemd[1]: user@1001.service: Passing 0 fds to service
Dec 08 09:35:54 host systemd[1]: user@1001.service: About to execute: 
/usr/lib/systemd/systemd --user
Dec 08 09:35:54 host systemd[1]: user@1001.service: Forked 
/usr/lib/systemd/systemd as 6899
Dec 08 09:35:54 host (systemd)[6899]: Found cgroup2 on /sys/fs/cgroup/, full 
unified hierarchy
Dec 08 09:35:54 host systemd[1]: user@1001.service: Changed dead -> start
Dec 08 09:35:54 host systemd[1]: Starting User Manager for UID 1001...
Dec 08 09:35:54 host (systemd)[6899]: Bind-mounting / on 
/run/systemd/mount-rootfs (MS_BIND|MS_REC "")...
Dec 08 09:35:54 host systemd[1]: user@1001.service: User lookup succeeded: 
uid=1001 gid=118
Dec 08 09:35:54 host (systemd)[6899]: Applying namespace mount on 
/run/systemd/mount-rootfs/run/credentials
Dec 08 09:35:54 host (systemd)[6899]: Bind-mounting 
/run/systemd/inaccessible/dir on /run/systemd/mount-rootfs/run/credentials 
(MS_BIND|MS_REC "")...
Dec 08 09:35:54 host (systemd)[6899]: Successfully mounted 
/run/systemd/inaccessible/dir to /run/systemd/mount-rootfs/run/credentials
Dec 08 09:35:54 host (systemd)[6899]: Applying namespace mount on 
/run/systemd/mount-rootfs/run/systemd/incoming
Dec 08 09:35:54 host (systemd)[6899]: Followed source symlinks 
/run/systemd/propagate/user@1001.service → 
/run/systemd/propagate/user@1001.service.
Dec 08 09:35:54 host (systemd)[6899]: Bind-mounting 
/run/systemd/propagate/user@1001.service on 
/run/systemd/mount-rootfs/run/systemd/incoming (MS_BIND "")...
Dec 08 09:35:54 host (systemd)[6899]: Successfully mounted 
/run/systemd/propagate/user@1001.service to 
/run/systemd/mount-rootfs/run/systemd/incoming
Dec 08 09:35:54 host (systemd)[6899]: Applying namespace mount on 
/run/systemd/mount-rootfs/sys
Dec 08 09:35:54 host (systemd)[6899]: Failed to umount 
/run/systemd/mount-rootfs/sys, ignoring: Device or resource busy
Dec 08 09:35:54 host (systemd)[6899]: Failed to umount 
/run/systemd/mount-rootfs/sys, ignoring: Device or resource busy
Dec 08 09:35:54 host (systemd)[6899]: Failed to umount 
/run/systemd/mount-rootfs/sys, ignoring: Device or resource busy
Dec 08 09:35:54 host (systemd)[6899]: Failed to umount 
/run/systemd/mount-rootfs/sys, ignoring: Device or resource busy
Dec 08 09:35:54 host (systemd)[6899]: Failed to umount 
/run/systemd/mount-rootfs/sys, ignoring: Device or resource busy
Dec 08 09:35:54 host (systemd)[6899]: Failed to umount 
/run/systemd/mount-rootfs/sys, ignoring: Device or resource busy
Dec 08 09:35:54 host (systemd)[6899]: Failed to umount 
/run/systemd/mount-rootfs/sys, ignoring: Device or resource busy
Dec 08 09:35:54 host (systemd)[6899]: Failed to umount 
/run/systemd/mount-rootfs/sys, ignoring: Device or resource busy
Dec 08 09:35:54 host (systemd)[6899]: Mounting sysfs (sysfs) on 
/run/systemd/mount-rootfs/sys (MS_NOSUID|MS_NODEV|MS_NOEXEC "")...
Dec 08 09:35:54 host (systemd)[6899]: user@1001.service: Executing: 
/usr/lib/systemd/systemd --user
Dec 08 09:35:54 host systemd[6899]: Failed to copy os-release for propagation, 
ignoring: Permission denied
Dec 08 09:35:54 host systemd[6899]: Failed to allocate manager object: 
Permission denied
Dec 08 09:35:54 host systemd[1]: user@1001.service: Got notification message 
from PID 6899 (ERRNO=13)
Dec 08 09:35:54 host systemd[1]: user@1001.service: Got notification message 
from PID 6899 (EXIT_STATUS=1)
Dec 08 09:35:54 host systemd[1]: user@1001.service: Child 6899 belongs to 
user@1001.service.
Dec 08 09:35:54 host systemd[1]: user@1001.service: Main process exited, 
code=exited, 

Re: how to keep eth link down across reboots ?

[lacsaP Patatetom]

it's not "systemd" way but may be by blacklisting the module used by the
network card ?
and inserting it when required...

regards, lacsaP.


Le jeu. 7 déc. 2023 à 17:12, lejeczek  a écrit :

> Hi guys.
>
> Perhaps not strictly _systemd_ question but community here surely is
> capable - a matter of me being lucky - how would you keep an Ethernet
> link/port powered down?
> I was thinking I'll try first _udev_ rules - given other tools/managers
> are told to stay away from the link/port
> Is there a better, best way to put such link/port down & keep it that way
> - naturally, please steer clear of "unplug the cable" type of ideas.
>
> many thanks, L.
>