atop package

[jai]

In ubuntu 18, I am not able to install anything using apt package manager
because of atop package.











*root@dummyhost:~# systemctl status atopacct.service● atopacct.service -
Atop process accounting daemon   Loaded: loaded
(/lib/systemd/system/atopacct.service; enabled; vendor preset: enabled)
 Active: failed (Result: protocol) since Thu 2023-12-14 12:10:00 WIB; 49s
ago Docs: man:atopacctd(8)Dec 14 12:10:00 smartpesantren2 systemd[1]:
Starting Atop process accounting daemon...Dec 14 12:10:00 smartpesantren2
atopacctd[367437]: /run/pacct_shadow.d: File existsDec 14 12:10:00
smartpesantren2 systemd[1]: atopacct.service: Can't open PID file
/run/atopacctd.pid (yet?) after start: No such file or directoryDec 14
12:10:00 smartpesantren2 systemd[1]: atopacct.service: Failed with result
'protocol'.Dec 14 12:10:00 smartpesantren2 systemd[1]: Failed to start Atop
process accounting daemon.*

The systemctl status shows error that /run/atopacctd.pid is missing.
I executed "ln -s /run/atop.pid /run/atopacctd.pid" to create symlink of
atopacctd.pid from atop.pid and then restarted the atopacct.service which
fixed the problem.
But is this the proper way to solve this issue?

Re: [RFC] initoverlayfs - a scalable initial filesystem

[Nils Kattenbeck]

On Wed, Dec 13, 2023 at 10:03 AM Lennart Poettering
 wrote:
>
> On Di, 12.12.23 23:01, Nils Kattenbeck (nilskem...@gmail.com) wrote:
>
> > > sysexts are erofs or squashfs file systems with verity backing. Only
> > > the sectors you access are decompressed.
> >
> > Okay I forgot that they were erofs based and mentioned cpio archives
> > so I assumed they would be one.
> > Do they need to be fully read from disk to generate the cpio archive?
>
> erofs is a file system, cpio is a serialized archive. Two different
> things. The discussion here is whether to pass the initrd to the
> kernel as one or the other. But noone is suggesting to convert one to
> the other at boot time.

I was referring to the following line from sd-stub's man page: "The
following resources are passed as initrd cpio archives to the booted
kernel: [...] /.extra/sysext/*.raw [...]". I assume the initrd
containing the sysexts has to be created at some point?

Re: Troubleshooting timedatectl and hostnamectl failed to activate service: timed out

[Mantas Mikulėnas]

Activation is not client-side, it's handled automatically by dbus-daemon –
which either spawns the service directly or starts it as a systemd service.

In this case, check whether your logs show systemd-hostnamed.service
attempting to start; either it fails to start (missing libraries?
Apparmor?) or dbus-daemon fails to contact systemd (pid1 crashed?).

On Wed, Dec 13, 2023, 19:45 Sean Caron  wrote:

> Hi everyone,
>
> I'm on Ubuntu 20.04 LTS, kernel version 5.4.0-163-generic, systemd 245
> (245.4-4ubuntu3.22).
>
> I have some systems where I am receiving the following error messages when
> people attempt to use timedatectl or hostnamectl:
>
>
> Failed to query server: Failed to activate service
> 'org.freedesktop.timedate1': timed out (service_start_timeout=25000ms)
>
> Failed to query system properties: Failed to activate service
> 'org.freedesktop.hostname1': timed out (service_start_timeout=25000ms)
>
>
> I tried setting SYSTEMD_LOG_LEVEL=debug and rerunning the commands and it
> didn't really give me anything useful for determining the root cause of the
> issue. Here's an example of that output for timedatectl status:
>
>
> Bus n/a: changing state UNSET → OPENING
> Bus n/a: changing state OPENING → AUTHENTICATING
> Bus n/a: changing state AUTHENTICATING → HELLO
> 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
> Got message type=method_return sender=org.freedesktop.DBus
> destination=:1.15318 path=n/a interface=n/a member=n/a cookie=1
> reply_cookie=1 signature=s error-name=n/a error-message=n/a
> Bus n/a: changing state HELLO → RUNNING
> Sent message type=method_call sender=n/a
> destination=org.freedesktop.timedate1 path=/org/freedesktop/timedate1
> interface=org.freedesktop.DBus.Properties member=GetAll cookie=2
> reply_cookie=0 signature=s error-name=n/a error-message=n/a
> Got message type=error sender=org.freedesktop.DBus destination=:1.15318
> path=n/a interface=n/a member=n/a cookie=3 reply_cookie=2 signature=s
> error-name=org.freedesktop.DBus.Error.TimedOut error-message=Failed to
> activate service 'org.freedesktop.timedate1': timed out
> (service_start_timeout=25000ms)
> Failed to query server: Failed to activate service
> 'org.freedesktop.timedate1': timed out (service_start_timeout=25000ms)
> Bus n/a: changing state RUNNING → CLOSED
>
>
> I read that sometimes these issues can be caused by filesystem permissions
> on subdirectories in /var such as /var/tmp or /var/lib/systemd but I
> checked these and compared against a working system and I don't see any
> obvious differences.
>
> I have tried using strace on timedatectl and hostnamectl to try and see
> what's hanging things up but that hasn't really provided any fruitful
> direction, either.
>
> I didn't really know this was occurring until an end user reported it to
> me so I don't necessarily know how long the issue has been occurring or
> have a change in mind that could have broken things. I'm not sure if the
> upgrade from Ubuntu 18 to Ubuntu 20 broke it, or if some security
> configuration broke it. Or perhaps there is a missing dependency package on
> the broken systems?
>
> Could anyone out there please provide a little bit more guidance on how I
> might troubleshoot this and determine the root cause of the issue? I
> really hate to bother folks here but I'm feeling stuck.
>
> Thank you!
>
> Sean
>

Troubleshooting timedatectl and hostnamectl failed to activate service: timed out

[Sean Caron]

Hi everyone,

I'm on Ubuntu 20.04 LTS, kernel version 5.4.0-163-generic, systemd 245
(245.4-4ubuntu3.22).

I have some systems where I am receiving the following error messages when
people attempt to use timedatectl or hostnamectl:


Failed to query server: Failed to activate service
'org.freedesktop.timedate1': timed out (service_start_timeout=25000ms)

Failed to query system properties: Failed to activate service
'org.freedesktop.hostname1': timed out (service_start_timeout=25000ms)


I tried setting SYSTEMD_LOG_LEVEL=debug and rerunning the commands and it
didn't really give me anything useful for determining the root cause of the
issue. Here's an example of that output for timedatectl status:


Bus n/a: changing state UNSET → OPENING
Bus n/a: changing state OPENING → AUTHENTICATING
Bus n/a: changing state AUTHENTICATING → HELLO
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
Got message type=method_return sender=org.freedesktop.DBus
destination=:1.15318 path=n/a interface=n/a member=n/a cookie=1
reply_cookie=1 signature=s error-name=n/a error-message=n/a
Bus n/a: changing state HELLO → RUNNING
Sent message type=method_call sender=n/a
destination=org.freedesktop.timedate1 path=/org/freedesktop/timedate1
interface=org.freedesktop.DBus.Properties member=GetAll cookie=2
reply_cookie=0 signature=s error-name=n/a error-message=n/a
Got message type=error sender=org.freedesktop.DBus destination=:1.15318
path=n/a interface=n/a member=n/a cookie=3 reply_cookie=2 signature=s
error-name=org.freedesktop.DBus.Error.TimedOut error-message=Failed to
activate service 'org.freedesktop.timedate1': timed out
(service_start_timeout=25000ms)
Failed to query server: Failed to activate service
'org.freedesktop.timedate1': timed out (service_start_timeout=25000ms)
Bus n/a: changing state RUNNING → CLOSED


I read that sometimes these issues can be caused by filesystem permissions
on subdirectories in /var such as /var/tmp or /var/lib/systemd but I
checked these and compared against a working system and I don't see any
obvious differences.

I have tried using strace on timedatectl and hostnamectl to try and see
what's hanging things up but that hasn't really provided any fruitful
direction, either.

I didn't really know this was occurring until an end user reported it to me
so I don't necessarily know how long the issue has been occurring or have a
change in mind that could have broken things. I'm not sure if the upgrade
from Ubuntu 18 to Ubuntu 20 broke it, or if some security configuration
broke it. Or perhaps there is a missing dependency package on the broken
systems?

Could anyone out there please provide a little bit more guidance on how I
might troubleshoot this and determine the root cause of the issue? I
really hate to bother folks here but I'm feeling stuck.

Thank you!

Sean

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

[Christopher Wong]

Hi Mantas,

I finally found out what was causing this mount issue. We have a global 
sandboxing configuration for all services, that implies PrivateNetwork=yes. 
According to manual this will imply PrivateMounts=yes. So, I added a drop-in 
configuration to 
user-runtime-dir@.service.d which defines 
PrivateMounts=no. Now it works! 

Thank you very much for your support!

Best regards,
Christopher Wong


From: systemd-devel  on behalf of 
Christopher Wong 
Date: Wednesday, 13 December 2023 at 11:32
To: Mantas Mikulėnas 
Cc: Systemd 
Subject: Re: [systemd-devel] Manual start of user@.service failed with 
permission denied
Hi Mantas,

I ran your suggestion and here is the result:

root@host:/run/user# ls -la
drwxr-xr-x2 root root40 Dec 13 11:24 .
drwxr-xr-x   99 root root  2160 Dec 13 11:00 ..
root@host:/run/user# /usr/lib/systemd/systemd-user-runtime-dir start 1001
root@host:/run/user# ls -la
drwxr-xr-x3 root root60 Dec 13 11:25 .
drwxr-xr-x   99 root root  2160 Dec 13 11:00 ..
drwx--2 ida  ssh-user40 Dec 13 11:25 1001
root@host:/run/user# mount | grep /run
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /run/user/1001 type tmpfs 
(rw,nosuid,nodev,relatime,size=97096k,nr_inodes=24274,mode=700,uid=1001,gid=118)

This seems to be correct, and I could see /run/user/1001 listed using “mount”.

Thank you for your explaination! We have probably be running with a uncomplete 
setup of the mount before.

Best regards,
Christopher Wong


From: Mantas Mikulėnas 
Date: Wednesday, 13 December 2023 at 10:33
To: Christopher Wong 
Cc: Systemd 
Subject: Re: [systemd-devel] Manual start of user@.service failed with 
permission denied
On Wed, Dec 13, 2023 at 10:36 AM Christopher Wong 
mailto:christopher.w...@axis.com>> wrote:
Hi Mantas,

I tried with StopWhenUnneeded=no in 
user-runtime-dir@.service, then when 
user@1001.service fails the status of 
user-runtime-dir@.service is active. At this 
state the directory /run/user/1001 is created, it is empty, owned by root. 
Running the mount command doesn’t show /run/user/1001.

Run the "/usr/lib/systemd/systemd-user-runtime-dir start 1001" manually and 
check whether the mounted filesystem is there afterwards.

If it's still not there, then run "mount -t tmpfs -o uid=1001,mode=0700 none 
/run/user/1001" and then check whether it stays mounted.



I have mentioned it before, but I want to point out that if I put 
“ExecStartPre=+chown %i /run/user/%i” in user@.service 
then the user@1001.service can be started manually. 
The mount command doesn’t show /run/user/1001 either, but since the service is 
started the path contains bus socket and systemd directory with content, which 
are the things I am after.

The main issue here is that /run/user/1001 is owned by root after 
user-runtime-dir@.service has been exited 
successfully.

No, that's only a symptom of the main issue.

The current design that systemd implements is to have a user-specific tmpfs 
mounted at that location (for quota purposes), and so the underlying mountpoint 
is deliberately created as owned by root – its ownership is not changed because 
it's supposed to have a new filesystem mounted on top (which would make the 
mountpoint hidden and its ownership moot).

If you specifically want to *not* have an additional tmpfs there, then you can 
continue using the manual "ExecStartPre=chown" (or in fact you could replace 
the entire user-runtime-dir@ with a simpler one that only mkdirs and chowns), 
but in that case you shouldn't be saying that it's a systemd issue that it 
doesn't chown something that it was never meant to chown to begin with.


Best regards,
Christopher Wong


From: Mantas Mikulėnas mailto:graw...@gmail.com>>
Date: Wednesday, 13 December 2023 at 08:08
To: Christopher Wong 
mailto:christopher.w...@axis.com>>
Cc: Systemd 
mailto:systemd-devel@lists.freedesktop.org>>
Subject: Re: [systemd-devel] Manual start of user@.service failed with 
permission denied
On Tue, Dec 12, 2023 at 6:15 PM Christopher Wong 
mailto:christopher.w...@axis.com>> wrote:
Hi Mantas,

After user@1001.service failed, it trigger the 
stopping process and become inactive.

Ah yeah, that makes sense, user-runtime-dir@ has StopWhenUnneeded=yes – so of 
course after user@1001 crashes you're not going to see anything mounted anymore.

Could you try temporarily removing that option / setting it to 'no', just to 
see what changes?



○ user-runtime-dir@1001.service - User 
Runtime Directory /run/user/1001

 Loaded: loaded 
(/etc/systemd/system/user-runtime-dir@.service;
 static)

Drop-In: 

Re: systemd units disabled when calling systemctl daemon-reload

[Etienne Cordonnier]

"I haven't noticed this behavior myself, and attempted a repro here on
v253 (Arch x86_64) just now."

-> Sorry for being unclear, I am talking about an embedded system with very
significant customization (yocto based) and fully expect that the
customization introduced the issue, so I didn't expect you to be able to
reproduce. I am rather debugging this and asking for input on how to debug
this kind of issue.

"What do you mean by "disabled"?"

-> I mean specifically that targets "basic.target", "local-fs.target" and
"multi-user.target" are in the state "LOAD=loaded, ACTIVE=inactive,
SUB=dead" after I call systemctl daemon-reload, whereas they are in the
state "LOAD=loaded,ACTIVE=active,SUB-active" after I boot the system. I am
trying to understand what causes this transition, but I don't see it in the
logs at the moment.

I am using systemd version 250.5 (plus the yocto patches):

# systemctl --version
systemd 250 (250.5+)
+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 -BZIP2 -LZ4
+XZ -ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT
default-hierarchy=hybrid


With the default info log-level, I only see those logs after calling
"systemctl daemon-reload":
~ # Reloading.
systemd-logind.service: Deactivated successfully.
systemd-resolved.service: Deactivated successfully.
systemd-networkd.service: Deactivated successfully.
...  (other services getting "deactivated")
~ #

I also tried reading the debug log-level logs, as well as the output of
dbus-monitor --system but I still don't understand where the error is.
Taking local-fs.target as an exemple, those are the logs from dbus-monitor
--system after running systemctl daemon-reload, but those logs actually
don't show an error:

```
signal time=1702459928.818819 sender=:1.0 -> destination=(null destination)
serial=509 path=/org/freedesktop/systemd1;
interface=org.freedesktop.systemd1.Manager; member=Reloading
   boolean true
...
signal time=1702459928.978736 sender=:1.0 -> destination=(null destination)
serial=1288 path=/org/freedesktop/systemd1;
interface=org.freedesktop.systemd1.Manager; member=UnitRemoved
   string "local-fs.target"
   object path "/org/freedesktop/systemd1/unit/local_2dfs_2etarget"
...
signal time=1702459929.769768 sender=:1.0 -> destination=(null destination)
serial=3395 path=/org/freedesktop/systemd1;
interface=org.freedesktop.systemd1.Manager; member=UnitNew
   string "local-fs.target"
   object path "/org/freedesktop/systemd1/unit/local_2dfs_2etarget"
...
signal time=1702459929.781640 sender=:1.0 -> destination=(null destination)
serial=3629 path=/org/freedesktop/systemd1;
interface=org.freedesktop.systemd1.Manager; member=JobNew
   uint32 829
   object path "/org/freedesktop/systemd1/job/829"
   string "local-fs.target"
signal time=1702459929.781678 sender=:1.0 -> destination=(null destination)
serial=3630 path=/org/freedesktop/systemd1;
interface=org.freedesktop.systemd1.Manager; member=Reloading
   boolean false
```

systemctl status local-fs.target also doesn't show why the unit is
"inactived (dead)".  How would you debug this kind of issue?

Thanks,
Etienne

On Tue, Dec 12, 2023 at 10:07 PM Lennart Poettering 
wrote:

> On Di, 12.12.23 19:06, Etienne Cordonnier (ecordonn...@snap.com) wrote:
>
> > Hello,
> > I am debugging some embedded system running systemd. The behavior I am
> > observing is that many systemd targets such as multi-user.target are
> > disabled after I run systemctl daemon-reload (as shown by systemctl
> > list-units --type target --all). This causes many systemd units to be
> > disabled, and forces me to reboot the system.
>
> What do you mean by "disabled"?
>
> in systemd targets can be active and inactive, and that's what
> "systemctl list-unit" shows. They can also be enabled/disabled, but
> that's what "systemctl list-unit-files" shows. But targets such as
> multi-user.target cannot be enabled nor disabled, they are considered
> "static", i.e. always enabled if you so will. Which "systemctl
> list-unit-file" should actually show.
>
> Hence, I don#t really grok what you are trying to say here...
>
> > Is there a way to debug this systemd target transition? I already
> > enabled systemctl
> > log-level debug, but I still don't understand why the systemd target is
> > changing when I call systemctl daemon-reload on this particular system.
>
> Please state OS, systemd version and provide relevant logs. Otherwise
> this is not actionable.
>
> Lennart
>
> --
> Lennart Poettering, Berlin
>

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

[Christopher Wong]

Hi Mantas,

I ran your suggestion and here is the result:

root@host:/run/user# ls -la
drwxr-xr-x2 root root40 Dec 13 11:24 .
drwxr-xr-x   99 root root  2160 Dec 13 11:00 ..
root@host:/run/user# /usr/lib/systemd/systemd-user-runtime-dir start 1001
root@host:/run/user# ls -la
drwxr-xr-x3 root root60 Dec 13 11:25 .
drwxr-xr-x   99 root root  2160 Dec 13 11:00 ..
drwx--2 ida  ssh-user40 Dec 13 11:25 1001
root@host:/run/user# mount | grep /run
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /run/user/1001 type tmpfs 
(rw,nosuid,nodev,relatime,size=97096k,nr_inodes=24274,mode=700,uid=1001,gid=118)

This seems to be correct, and I could see /run/user/1001 listed using “mount”.

Thank you for your explaination! We have probably be running with a uncomplete 
setup of the mount before.

Best regards,
Christopher Wong


From: Mantas Mikulėnas 
Date: Wednesday, 13 December 2023 at 10:33
To: Christopher Wong 
Cc: Systemd 
Subject: Re: [systemd-devel] Manual start of user@.service failed with 
permission denied
On Wed, Dec 13, 2023 at 10:36 AM Christopher Wong 
mailto:christopher.w...@axis.com>> wrote:
Hi Mantas,

I tried with StopWhenUnneeded=no in 
user-runtime-dir@.service, then when 
user@1001.service fails the status of 
user-runtime-dir@.service is active. At this 
state the directory /run/user/1001 is created, it is empty, owned by root. 
Running the mount command doesn’t show /run/user/1001.

Run the "/usr/lib/systemd/systemd-user-runtime-dir start 1001" manually and 
check whether the mounted filesystem is there afterwards.

If it's still not there, then run "mount -t tmpfs -o uid=1001,mode=0700 none 
/run/user/1001" and then check whether it stays mounted.



I have mentioned it before, but I want to point out that if I put 
“ExecStartPre=+chown %i /run/user/%i” in user@.service 
then the user@1001.service can be started manually. 
The mount command doesn’t show /run/user/1001 either, but since the service is 
started the path contains bus socket and systemd directory with content, which 
are the things I am after.

The main issue here is that /run/user/1001 is owned by root after 
user-runtime-dir@.service has been exited 
successfully.

No, that's only a symptom of the main issue.

The current design that systemd implements is to have a user-specific tmpfs 
mounted at that location (for quota purposes), and so the underlying mountpoint 
is deliberately created as owned by root – its ownership is not changed because 
it's supposed to have a new filesystem mounted on top (which would make the 
mountpoint hidden and its ownership moot).

If you specifically want to *not* have an additional tmpfs there, then you can 
continue using the manual "ExecStartPre=chown" (or in fact you could replace 
the entire user-runtime-dir@ with a simpler one that only mkdirs and chowns), 
but in that case you shouldn't be saying that it's a systemd issue that it 
doesn't chown something that it was never meant to chown to begin with.


Best regards,
Christopher Wong


From: Mantas Mikulėnas mailto:graw...@gmail.com>>
Date: Wednesday, 13 December 2023 at 08:08
To: Christopher Wong 
mailto:christopher.w...@axis.com>>
Cc: Systemd 
mailto:systemd-devel@lists.freedesktop.org>>
Subject: Re: [systemd-devel] Manual start of user@.service failed with 
permission denied
On Tue, Dec 12, 2023 at 6:15 PM Christopher Wong 
mailto:christopher.w...@axis.com>> wrote:
Hi Mantas,

After user@1001.service failed, it trigger the 
stopping process and become inactive.

Ah yeah, that makes sense, user-runtime-dir@ has StopWhenUnneeded=yes – so of 
course after user@1001 crashes you're not going to see anything mounted anymore.

Could you try temporarily removing that option / setting it to 'no', just to 
see what changes?



○ user-runtime-dir@1001.service - User 
Runtime Directory /run/user/1001

 Loaded: loaded 
(/etc/systemd/system/user-runtime-dir@.service;
 static)

Drop-In: /usr/lib/systemd/system/service.d

 └─10-axis.conf, 20-axis-sandbox.conf

 Active: inactive (dead) since Tue 2023-12-12 16:33:35 CET; 36min ago

   Duration: 315ms

   Docs: man:user@.service(5)

Process: 16325 ExecStartPre=ls -la /run/user (code=exited, status=0/SUCCESS)

Process: 16327 ExecStartPre=mount (code=exited, status=0/SUCCESS)

Process: 16329 ExecStart=/usr/lib/systemd/systemd-user-runtime-dir start 
1001 (code=exited, status=0/SUCCESS)

Process: 16334 ExecStartPost=sleep 5 (code=exited, status=0/SUCCESS)

Process: 16347 ExecStartPost=ls -la /run/user/1001 (code=exited, 
status=0/SUCCESS)

Process: 16351 ExecStartPost=mount 

Query on dynamic update of Kernel comandline

[HARSHAL PATIL (QUIC)]

Hello Fellow Community,

I have a following question. Your help will be really appreciated.

"Kernel expects few params from kernel cmdline from underlying firmware. Is 
there any mechanism to dynamically update the cmdline updated by firmware 
(UEFI) during boot time in systemd-boot similar to DT fixup protocol ?"

Example : androidboot.serialno is read from firmware and needs to be appended 
to kernel commandline



Best Regards,

Harshal Patil

Re: networkd: learned DNS server not propagated to rdnss option in RA

[Michael Heimpold]

Am Mittwoch, 13. Dezember 2023, 09:01:46 CET schrieb Andrei Borzenkov:
> On Wed, Dec 13, 2023 at 10:46 AM Michael Heimpold  wrote:
> > Dear all,
> > 
> > I'm trying to setup an embedded system as IPv6 router using IPv6
> > prefix delegation. The system has two network interfaces, eth0 and
> > eth1. eth0 is the upstream interface, but it is part of a bridge
> > interface,
> > but I think this does not play an important role here.
> > The upstream interfaces acquires an IPv6 via RA and also learns
> > the DNS server from the upstream router. IPv6 and DNS resolving
> > works properly on the system.
> > (note: the upstream interface is dual-stack, IPv4 is also working as
> > usual).
> > 
> > The goal is to pass routable IPv6 addesses down to a system connected
> > via eth1 ("client"). In my understanding, this is what IPv6 prefix
> > delegation is for and it is working so far, that the client acquires an
> > IPv6 and I can ping IPv6 addresses on the Internet etc.
> > However, when I look at the IPv6 RA sent out on eth1 interface, the rdnss
> > option is missing, so that the client does not learn any DNS server over
> > the link.
> > 
> > Please find below my configuration files. My understanding of the
> > documentation is, that this should work out-of-the-box since all related
> > config options have reasonable defaults (EmitDNS, UseDNS...), so that
> > learned DNS server from upstream interfaces should propagate to the RAs
> > of the downstream interface. But this is not the case.
> > If I manually configure DNS=... option in the "IPv6SendRA" section, then a
> > rdnss field is part of the RA and then the client learns the DNS server
> > and
> > I also have DNS on the client working. So this is not an issue on the
> > client itself.
> > 
> > On my system, I'm using systemd-networkd v250.5 from Yocto kirkstone,
> > but I also tested v254.4 with no difference in behavior.
> > 
> > My question is whether I have a wrong understanding or might this be a
> > bug?
> > Any hints are appreciated.
> > 
> > Thanks,
> > Michael
> > 
> > 
> > --snip: /lib/systemd/network/br0.network--
> > [Match]
> > Name=br0
> > 
> > [Network]
> > DHCP=yes
> > IPv6AcceptRA=yes
> > 
> > [DHCPv4]
> > ClientIdentifier=mac
> > UseHostname=no
> > 
> > [DHCPv6]
> > UseHostname=no
> > --snap--
> > 
> > --snip: /etc/systemd/network/eth1.network--
> > [Match]
> > Name=eth1
> > 
> > [Network]
> > DHCP=no
> > IPv6AcceptRA=no
> > IPForward=ipv6
> > IPv6SendRA=yes
> > DHCPPrefixDelegation=yes
> > --snap--
> 
> Quoting documentation
> 
> --><--
> DNS servers from the uplink interface specified in UplinkInterface= will be
> used --><--
> 
> Try adding
> 
> UplinkInterface=br0


Quoting again the documentation:
--><--
UplinkInterface=

Specifies the name or the index of the uplink interface, or one of the special 
values ":none" and ":auto". When emitting DNS servers or search domains is 
enabled but no servers are specified, the servers configured in the uplink 
interface will be emitted. When ":auto", the value specified to the same 
setting in the [DHCPPrefixDelegation] section will be used if 
DHCPPrefixDelegation= is enabled, otherwise the link which has a default 
gateway with the highest priority will be automatically selected. When 
":none", no uplink interface will be selected. Defaults to ":auto".
--><--

So ":auto" should be the default, since I did not set it.

I tried to set it explicitly to "br0" as you suggested, but it does not change 
anything :-(

(More over, I'd also keep it unspecified since on another system where I want 
to use the same feature later, I have two upstream interfaces and I don't know
which one will actually be used by customer - so having a fixed configuration 
would be not that ideal for me - but this is not yet important).

But thanks for your hint,
best
Michael

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

[Mantas Mikulėnas]

On Wed, Dec 13, 2023 at 10:36 AM Christopher Wong 
wrote:

> Hi Mantas,
>
>
>
> I tried with StopWhenUnneeded=no in user-runtime-dir@.service, then when
> user@1001.service fails the status of user-runtime-dir@.service is
> active. At this state the directory /run/user/1001 is created, it is empty,
> owned by root. Running the mount command doesn’t show /run/user/1001.
>

Run the "/usr/lib/systemd/systemd-user-runtime-dir start 1001" manually and
check whether the mounted filesystem is there afterwards.

If it's still not there, then run "mount -t tmpfs -o uid=1001,mode=0700
none /run/user/1001" and then check whether it stays mounted.


>
>
> I have mentioned it before, but I want to point out that if I put 
> “ExecStartPre=+chown
> %i /run/user/%i” in user@.service then the user@1001.service can be
> started manually. The mount command doesn’t show /run/user/1001 either, but
> since the service is started the path contains bus socket and systemd
> directory with content, which are the things I am after.
>
>
>
> The main issue here is that /run/user/1001 is owned by root after
> user-runtime-dir@.service has been exited successfully.
>

No, that's only a symptom of the main issue.

The current design that systemd implements is to have a user-specific tmpfs
mounted at that location (for quota purposes), and so the underlying
mountpoint is deliberately created as owned by root – its ownership is not
changed because it's supposed to have a new filesystem mounted on top
(which would make the mountpoint hidden and its ownership moot).

If you specifically want to *not* have an additional tmpfs there, then you
can continue using the manual "ExecStartPre=chown" (or in fact you could
replace the entire user-runtime-dir@ with a simpler one that only mkdirs
and chowns), but in that case you shouldn't be saying that it's a systemd
issue that it doesn't chown something that it was never meant to chown to
begin with.


>
>
> Best regards,
>
> Christopher Wong
>
>
>
>
>
> *From: *Mantas Mikulėnas 
> *Date: *Wednesday, 13 December 2023 at 08:08
> *To: *Christopher Wong 
> *Cc: *Systemd 
> *Subject: *Re: [systemd-devel] Manual start of user@.service failed
> with permission denied
>
> On Tue, Dec 12, 2023 at 6:15 PM Christopher Wong <
> christopher.w...@axis.com> wrote:
>
> Hi Mantas,
>
>
>
> After user@1001.service failed, it trigger the stopping process and
> become inactive.
>
>
>
> Ah yeah, that makes sense, user-runtime-dir@ has StopWhenUnneeded=yes –
> so of course after user@1001 crashes you're not going to see anything
> mounted anymore.
>
>
>
> Could you try temporarily removing that option / setting it to 'no', just
> to see what changes?
>
>
>
>
>
> ○ user-runtime-dir@1001.service - User Runtime Directory /run/user/1001
>
>  Loaded: loaded (/etc/systemd/system/user-runtime-dir@.service;
> static)
>
> Drop-In: /usr/lib/systemd/system/service.d
>
>  └─10-axis.conf, 20-axis-sandbox.conf
>
>  Active: inactive (dead) since Tue 2023-12-12 16:33:35 CET; 36min ago
>
>Duration: 315ms
>
>Docs: man:user@.service(5)
>
> Process: 16325 ExecStartPre=ls -la /run/user (code=exited,
> status=0/SUCCESS)
>
> Process: 16327 ExecStartPre=mount (code=exited, status=0/SUCCESS)
>
> Process: 16329 ExecStart=/usr/lib/systemd/systemd-user-runtime-dir
> start 1001 (code=exited, status=0/SUCCESS)
>
> Process: 16334 ExecStartPost=sleep 5 (code=exited, status=0/SUCCESS)
>
> Process: 16347 ExecStartPost=ls -la /run/user/1001 (code=exited,
> status=0/SUCCESS)
>
> Process: 16351 ExecStartPost=mount (code=exited, status=0/SUCCESS)
>
> Process: 16361 ExecStop=/usr/lib/systemd/systemd-user-runtime-dir
> stop 1001 (code=exited, status=0/SUCCESS)
>
>Main PID: 16329 (code=exited, status=0/SUCCESS)
>
> CPU: 48ms
>
>
>
> /etc/fstab don’t include anything on /run/user/1001 and there is no mount
> unit for run-user-1001.mount either.
>
>
>
> Best regards,
>
> Christopher Wong
>
>
>
>
>
> *From: *Mantas Mikulėnas 
> *Date: *Tuesday, 12 December 2023 at 17:05
> *To: *Christopher Wong 
> *Cc: *Systemd 
> *Subject: *Re: [systemd-devel] Manual start of user@.service failed
> with permission denied
>
> That sounds like it's getting immediately unmounted (or maybe not being
> mounted at all despite the program doing so).
>
>
>
> Does the user-runtime-dir service continue to show as "active" after this,
> or does it return to "inactive"?
>
>
>
> Does your /etc/fstab have any mentions of /run/user/1001? Or more
> generally, are there any run-user-1001.mount units? (If you 'systemctl
> status' this unit, does the status include a source path?)
>
>
>
> On Tue, Dec 12, 2023, 17:34 Christopher Wong 
> wrote:
>
> Hi Mantas,
>
>
>
> I currently have the following flow:
>
>
>
>1. No /run/user/1001 directory
>2. systemctl start user@1001.service
>3. systemd start user-runtime-dir@1001.service which ends successfully.
>4. The directory /run/user/1001 exists now, but is empty, 

Re: [RFC] initoverlayfs - a scalable initial filesystem

[Lennart Poettering]

On Di, 12.12.23 23:01, Nils Kattenbeck (nilskem...@gmail.com) wrote:

> > sysexts are erofs or squashfs file systems with verity backing. Only
> > the sectors you access are decompressed.
>
> Okay I forgot that they were erofs based and mentioned cpio archives
> so I assumed they would be one.
> Do they need to be fully read from disk to generate the cpio archive?

erofs is a file system, cpio is a serialized archive. Two different
things. The discussion here is whether to pass the initrd to the
kernel as one or the other. But noone is suggesting to convert one to
the other at boot time.

Lennart

--
Lennart Poettering, Berlin

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

[Christopher Wong]

Hi Mantas,

I tried with StopWhenUnneeded=no in 
user-runtime-dir@.service, then when 
user@1001.service fails the status of 
user-runtime-dir@.service is active. At this 
state the directory /run/user/1001 is created, it is empty, owned by root. 
Running the mount command doesn’t show /run/user/1001.

● user-runtime-dir@1001.service - User Runtime Directory /run/user/1001
 Loaded: loaded (/etc/systemd/system/user-runtime-dir@.service; static)
Drop-In: /usr/lib/systemd/system/service.d
 └─10-axis.conf, 20-axis-sandbox.conf
 Active: active (exited) since Wed 2023-12-13 09:16:57 CET; 33s ago
   Docs: man:user@.service(5)
Process: 133303 ExecStartPre=ls -la /run/user (code=exited, 
status=0/SUCCESS)
Process: 133305 ExecStartPre=mount (code=exited, status=0/SUCCESS)
Process: 133307 ExecStart=/usr/lib/systemd/systemd-user-runtime-dir start 
1001 (code=exited, status=0/SUCCESS)
Process: 133309 ExecStartPost=ls -la /run/user/1001 (code=exited, 
status=0/SUCCESS)
Process: 133310 ExecStartPost=mount (code=exited, status=0/SUCCESS)
   Main PID: 133307 (code=exited, status=0/SUCCESS)
CPU: 209ms


I have mentioned it before, but I want to point out that if I put 
“ExecStartPre=+chown %i /run/user/%i” in user@.service 
then the user@1001.service can be started manually. 
The mount command doesn’t show /run/user/1001 either, but since the service is 
started the path contains bus socket and systemd directory with content, which 
are the things I am after.

The main issue here is that /run/user/1001 is owned by root after 
user-runtime-dir@.service has been exited 
successfully.

Best regards,
Christopher Wong


From: Mantas Mikulėnas 
Date: Wednesday, 13 December 2023 at 08:08
To: Christopher Wong 
Cc: Systemd 
Subject: Re: [systemd-devel] Manual start of user@.service failed with 
permission denied
On Tue, Dec 12, 2023 at 6:15 PM Christopher Wong 
mailto:christopher.w...@axis.com>> wrote:
Hi Mantas,

After user@1001.service failed, it trigger the 
stopping process and become inactive.

Ah yeah, that makes sense, user-runtime-dir@ has StopWhenUnneeded=yes – so of 
course after user@1001 crashes you're not going to see anything mounted anymore.

Could you try temporarily removing that option / setting it to 'no', just to 
see what changes?



○ user-runtime-dir@1001.service - User 
Runtime Directory /run/user/1001

 Loaded: loaded 
(/etc/systemd/system/user-runtime-dir@.service;
 static)

Drop-In: /usr/lib/systemd/system/service.d

 └─10-axis.conf, 20-axis-sandbox.conf

 Active: inactive (dead) since Tue 2023-12-12 16:33:35 CET; 36min ago

   Duration: 315ms

   Docs: man:user@.service(5)

Process: 16325 ExecStartPre=ls -la /run/user (code=exited, status=0/SUCCESS)

Process: 16327 ExecStartPre=mount (code=exited, status=0/SUCCESS)

Process: 16329 ExecStart=/usr/lib/systemd/systemd-user-runtime-dir start 
1001 (code=exited, status=0/SUCCESS)

Process: 16334 ExecStartPost=sleep 5 (code=exited, status=0/SUCCESS)

Process: 16347 ExecStartPost=ls -la /run/user/1001 (code=exited, 
status=0/SUCCESS)

Process: 16351 ExecStartPost=mount (code=exited, status=0/SUCCESS)

Process: 16361 ExecStop=/usr/lib/systemd/systemd-user-runtime-dir stop 1001 
(code=exited, status=0/SUCCESS)

   Main PID: 16329 (code=exited, status=0/SUCCESS)

CPU: 48ms

/etc/fstab don’t include anything on /run/user/1001 and there is no mount unit 
for run-user-1001.mount either.

Best regards,
Christopher Wong


From: Mantas Mikulėnas mailto:graw...@gmail.com>>
Date: Tuesday, 12 December 2023 at 17:05
To: Christopher Wong 
mailto:christopher.w...@axis.com>>
Cc: Systemd 
mailto:systemd-devel@lists.freedesktop.org>>
Subject: Re: [systemd-devel] Manual start of user@.service failed with 
permission denied
That sounds like it's getting immediately unmounted (or maybe not being mounted 
at all despite the program doing so).

Does the user-runtime-dir service continue to show as "active" after this, or 
does it return to "inactive"?

Does your /etc/fstab have any mentions of /run/user/1001? Or more generally, 
are there any run-user-1001.mount units? (If you 'systemctl status' this unit, 
does the status include a source path?)

On Tue, Dec 12, 2023, 17:34 Christopher Wong 
mailto:christopher.w...@axis.com>> wrote:
Hi Mantas,

I currently have the following flow:


  1.  No /run/user/1001 directory
  2.  systemctl start user@1001.service
  3.  systemd start 
user-runtime-dir@1001.service which ends 
successfully.
  4.  The directory /run/user/1001 exists now, but is empty, owned by root with 

Re: networkd: learned DNS server not propagated to rdnss option in RA

[Andrei Borzenkov]

On Wed, Dec 13, 2023 at 10:46 AM Michael Heimpold  wrote:
>
> Dear all,
>
> I'm trying to setup an embedded system as IPv6 router using IPv6
> prefix delegation. The system has two network interfaces, eth0 and
> eth1. eth0 is the upstream interface, but it is part of a bridge interface,
> but I think this does not play an important role here.
> The upstream interfaces acquires an IPv6 via RA and also learns
> the DNS server from the upstream router. IPv6 and DNS resolving
> works properly on the system.
> (note: the upstream interface is dual-stack, IPv4 is also working as usual).
>
> The goal is to pass routable IPv6 addesses down to a system connected
> via eth1 ("client"). In my understanding, this is what IPv6 prefix delegation
> is for and it is working so far, that the client acquires an IPv6 and I can
> ping IPv6 addresses on the Internet etc.
> However, when I look at the IPv6 RA sent out on eth1 interface, the rdnss
> option is missing, so that the client does not learn any DNS server over the
> link.
>
> Please find below my configuration files. My understanding of the
> documentation is, that this should work out-of-the-box since all related
> config options have reasonable defaults (EmitDNS, UseDNS...), so that
> learned DNS server from upstream interfaces should propagate to the RAs
> of the downstream interface. But this is not the case.
> If I manually configure DNS=... option in the "IPv6SendRA" section, then a
> rdnss field is part of the RA and then the client learns the DNS server and
> I also have DNS on the client working. So this is not an issue on the
> client itself.
>
> On my system, I'm using systemd-networkd v250.5 from Yocto kirkstone,
> but I also tested v254.4 with no difference in behavior.
>
> My question is whether I have a wrong understanding or might this be a bug?
> Any hints are appreciated.
>
> Thanks,
> Michael
>
>
> --snip: /lib/systemd/network/br0.network--
> [Match]
> Name=br0
>
> [Network]
> DHCP=yes
> IPv6AcceptRA=yes
>
> [DHCPv4]
> ClientIdentifier=mac
> UseHostname=no
>
> [DHCPv6]
> UseHostname=no
> --snap--
>
> --snip: /etc/systemd/network/eth1.network--
> [Match]
> Name=eth1
>
> [Network]
> DHCP=no
> IPv6AcceptRA=no
> IPForward=ipv6
> IPv6SendRA=yes
> DHCPPrefixDelegation=yes
> --snap--
>

Quoting documentation

--><--
DNS servers from the uplink interface specified in UplinkInterface= will be used
--><--

Try adding

UplinkInterface=br0