Re: [systemd-devel] systemd | Requires statement with an instantiated service
On 02.09.2021 01:19, Leon Fauster wrote: > Dear list, > > following requirement exists here (systemd-239 installed): > > Applying a "Requires" statement with an instantiated service. > > Example: > > a@.service > b.service > > a@.service is started as a@host1.service and b.service must be started > after a@host1.service but the unit will be differently parameterized > (depended of the region). So I want to generalize the requires statement. If you need to manually instantiate a@.service, you can just as well manually add necessary Requires at the same time. E.g. a@.service: [Install] RequiredBy=b.service systemctl enable a@your-region.service > > My dropin file in ./b.service.d/dep.conf looks like > > [Unit] > Requires="a@*.service" > > This just produces following error: > 'Failed to add dependency on "a@*.service", ignoring: Invalid argument' > > I use also a Before=b.service statement for a@.service but that is not > enough. > Why?
[systemd-devel] systemd | Requires statement with an instantiated service
Dear list, following requirement exists here (systemd-239 installed): Applying a "Requires" statement with an instantiated service. Example: a@.service b.service a@.service is started as a@host1.service and b.service must be started after a@host1.service but the unit will be differently parameterized (depended of the region). So I want to generalize the requires statement. My dropin file in ./b.service.d/dep.conf looks like [Unit] Requires="a@*.service" This just produces following error: 'Failed to add dependency on "a@*.service", ignoring: Invalid argument' I use also a Before=b.service statement for a@.service but that is not enough. Any hints? -- Thanks, Leon
[systemd-devel] Using LoadCredential for passing API key to s3 bucket mount unit
Hi,
I am playing with the idea of using systemd mount to mount S3 bucket on
the system using s3fs.
To mount a bucket, an API key is required. s3fs can read the API key
from a file specified as an option:
s3fs $bucket_name $where -o passwd_file=${PATH_TO_PASSWORD_FILE} ...
I tried to set up a .mount unit with LoadCredential directive:
[Unit]
Description=tmp bucket mount
After=network.target
[Mount]
What=temp-bucket
Where=/mnt/tmp
Type=fuse.s3fs
LoadCredential=password_file:/etc/s3fs/tmp_key
Options=passwd_file="${CREDENTIALS_DIRECTORY}"/password_file,url=https://s3...
[Install]
WantedBy=multi-user.target
However mount start fails with s3fs not being able to read from
passwd_file:
s3fs: specified passwd_file is not readable.
I have used a small wrapper that calls env before calling s3fs to
investigate, and it appears that during the mount command execution
${CREDENTIALS_DIRECTORY} is created, but there is no subdirectory
corresponding to the unit name.
Is this a correct use for LoadCredential?
systemctl --version
systemd 248 (248)
+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 -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified
OS: Gentoo
--
With best regards,
--
Vladimir Timofeenko
[systemd-devel] Unable to boot Linux distribution ISO files that have systemd services
I am unable to boot up ISO files of Linux distributions that use systemd. My computer is a HP Pavilion TG01-2856no, it is recent hardware. The boot gets stuck when it tries to start systemd services, such as Network Time Synchronization. For example, there are the messages I get when trying to boot up the Arch Linux ISO: https://imgur.com/a/oKGjZk7 Booting it with the kernel argument init=/bin/bash however works.
Re: [systemd-devel] mkosi: rpm using host machine's users/groups
Colin Guthrie wrote on 01/09/2021 14:30: rpm -qa | xargs rpm --setugids >/dev/null 2>&1 Correction: --restore is actually needed over --setugids as although only the latter is strictly needed, it seems without the former the setuid bits on e.g. /usr/bin/su etc are also reset, so --restore is the required option to not break things in different ways! Sadly it's even slower than --setugids (takes almost twice as long) -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
[systemd-devel] mkosi: rpm using host machine's users/groups
Hi, So I didn't appreciate this before, but it seems a long standing RPM issue where, when using --root the packages will be installed with the uid/gid mappings from the host machine rather than the passwd/group files from the root. This makes for a problem using mkosi as it doesn't make the builds repeatable and very much dependant on the host machine. For now, I've added the following to my mkosi.postinst: rpm -qa | xargs rpm --setugids >/dev/null 2>&1 (for an RPM based target distro this is fine, but obviously others will presumably have similar commands). This, however, isn't cheap. It takes ~1 minute on a small package list on my semi-recent SSD laptop. That's pretty much the same time it takes to install the packages in the first place. So my question is, is there a better work around for this? Upstream RPM issue: https://github.com/rpm-software-management/rpm/issues/882 While I don't think it helps, the user namespaces may be a useful work around (e.g. semi related to https://github.com/systemd/mkosi/issues/716) but I think the real fix is likely in glibc/rpm. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [systemd-devel] Upgraded multiple systems to systemd 249.3 and all had eth1 not started / configured
On 18/08/21 12:24 pm, Amish wrote: Hello Further to my previous email: I see that there is already an *extremely similar issue* reported on July 12, 2021 and it has been fixed. https://github.com/systemd/systemd/issues/20203 But I do not know if this fix exists in systemd v249.3 (Arch Linux) If it exists that means that fix is breaking my system. And if it does not exist that means, I can expect it to fix my issue. systemd v249.4 seems to have fixed the issue. (Arch Linux) Regards Amish Regards, Amish. On 18/08/21 11:42 am, Amish wrote: Hello, Thank you for your reply. I can understand that there can be race. *But when I check logs, there is no race happening*. *Let us see and analyze the logs.* Stage 1: System boots, and kernel assigns eth0, eth1 and eth2 as interface names. Aug 18 09:17:13 kk kernel: e1000e :00:1f.6 eth0: (PCI Express:2.5GT/s:Width x1) e0:d5:5e:8d:7f:2f Aug 18 09:17:13 kk kernel: e1000e :00:1f.6 eth0: Intel(R) PRO/1000 Network Connection Aug 18 09:17:13 kk kernel: e1000e :00:1f.6 eth0: MAC: 13, PHY: 12, PBA No: FF-0FF Aug 18 09:17:13 kk kernel: 8139too :04:00.0 eth1: RealTek RTL8139 at 0x0e8fc9bb, 00:e0:4d:05:ee:a2, IRQ 19 Aug 18 09:17:13 kk kernel: r8169 :02:00.0 eth2: RTL8168e/8111e, 50:3e:aa:05:2b:ca, XID 2c2, IRQ 129 Aug 18 09:17:13 kk kernel: r8169 :02:00.0 eth2: jumbo features [frames: 9194 bytes, tx checksumming: ko] Stage 2: Now udev rules are triggered and the interfaces are renamed to tmpeth0, tmpeth2 and tmpeth1. Aug 18 09:17:13 kk kernel: 8139too :04:00.0 tmpeth2: renamed from eth1 Aug 18 09:17:13 kk kernel: e1000e :00:1f.6 tmpeth0: renamed from eth0 Aug 18 09:17:13 kk kernel: r8169 :02:00.0 tmpeth1: renamed from eth2 Stage 3: Now my script is called and it renames interfaces to eth0, eth2 and eth1. Aug 18 09:17:13 kk kernel: e1000e :00:1f.6 eth0: renamed from tmpeth0 Aug 18 09:17:14 kk kernel: r8169 :02:00.0 eth1: renamed from tmpeth1 Aug 18 09:17:14 kk kernel: 8139too :04:00.0 eth2: renamed from tmpeth2 Effectively original interface eth1 and eth2 are swapped. While eth0 remains eth0. All these happened before systemd-networkd started and interface renaming was over by 9:17:14. Stage 4: Now systemd-networkd starts, 2 seconds after all interface have been assigned their final names. Aug 18 09:17:16 kk systemd[1]: Starting Network Configuration... Aug 18 09:17:17 kk systemd-networkd[426]: lo: Link UP Aug 18 09:17:17 kk systemd-networkd[426]: lo: Gained carrier Aug 18 09:17:17 kk systemd-networkd[426]: Enumeration completed Aug 18 09:17:17 kk systemd[1]: Started Network Configuration. Aug 18 09:17:17 kk systemd-networkd[426]: eth2: Interface name change detected, renamed to eth1. Aug 18 09:17:17 kk systemd-networkd[426]: Could not process link message: File exists Aug 18 09:17:17 kk systemd-networkd[426]: eth1: Failed Aug 18 09:17:17 kk systemd-networkd[426]: eth1: Interface name change detected, renamed to eth2. Aug 18 09:17:17 kk systemd-networkd[426]: eth1: Interface name change detected, renamed to tmpeth2. Aug 18 09:17:17 kk systemd-networkd[426]: eth0: Interface name change detected, renamed to tmpeth0. Aug 18 09:17:17 kk systemd-networkd[426]: eth2: Interface name change detected, renamed to tmpeth1. Aug 18 09:17:17 kk systemd-networkd[426]: tmpeth0: Interface name change detected, renamed to eth0. Aug 18 09:17:17 kk systemd-networkd[426]: tmpeth1: Interface name change detected, renamed to eth1. Aug 18 09:17:17 kk systemd-networkd[426]: tmpeth2: Interface name change detected, renamed to eth2. Aug 18 09:17:17 kk systemd-networkd[426]: eth1: Link UP Aug 18 09:17:17 kk systemd-networkd[426]: eth0: Link UP Aug 18 09:17:20 kk systemd-networkd[426]: eth0: Gained carrier This is when eth0 and eth1 interfaces are up and configured by systemd-networkd but eth2 is down and not configured. *None of the .network configuration files match by interface names. They all match just by MAC address. *# sample .network file. [Match] MACAddress=e0:d5:5e:8d:7f:2f Type=ether [Network] IgnoreCarrierLoss=yes LinkLocalAddressing=no IPv6AcceptRA=no ConfigureWithoutCarrier=true Address=192.168.25.2/24 * * Above error message "eth1: failed", was not showing earlier version of systemd. So recent version of systemd-networkd is doing something different and this is where something is going wrong. Stage 5: (my workaround for this issue) I wrote a new service file which restarts systemd-networkd after waiting for 10 seconds. Aug 18 09:17:27 kk systemd[1]: Stopping Network Configuration... Aug 18 09:17:27 kk systemd[1]: systemd-networkd.service: Deactivated successfully. Aug 18 09:17:27 kk systemd[1]: Stopped Network Configuration. Aug 18 09:17:27 kk systemd[1]: Starting Network Configuration... Aug 18 09:17:27 kk systemd-networkd[579]: eth1: Link UP Aug 18 09:17:27 kk systemd-networkd[579]: eth0: Link UP Aug 18 09:17:27 kk systemd-networkd[579]: eth0: Gaine
Re: [systemd-devel] Unable to boot Linux distribution ISO files that have systemd services
On Wed, Sep 1, 2021 at 2:40 PM EpicLemon99 wrote: > I am unable to boot up ISO files of Linux distributions that use systemd. > My computer is a HP Pavilion TG01-2856no, it is recent hardware. The boot > gets stuck when it tries to start systemd services, such as Network Time > Synchronization. > > For example, there are the messages I get when trying to boot up the Arch > Linux ISO: https://imgur.com/a/oKGjZk7 > > Booting it with the kernel argument init=/bin/bash however works. Boot it with the 'systemd.debug-shell' option and take a look (via tty9) at what systemd-udevd is doing. I'm guessing that one of its worker processes tried to interact with a device (e.g. read information from /sys or do some active probing), but due to either hardware issue or driver bug, the syscall got stuck in the kernel and never returned. So check /proc/PID/stack of the udev worker processes, I guess? (The same issue might be occurring even on installed systems, only they don't *wait* for udev to finish handling every single device (systemd-udev-settle), so the process might just remain hung in background.) -- Mantas Mikulėnas
Re: [systemd-devel] systemd-udevd: Race condition when rule starts both a systemd-mount and an unit accessing that mount
Am Mi, 25. Aug 2021, um 18:51, schrieb Andrei Borzenkov:
> On Wed, Aug 25, 2021 at 3:44 PM Andrei Borzenkov wrote:
> ...
> > > Here's the udev rule:
> > > ```
> > > ACTION=="add", SUBSYSTEMS=="usb", SUBSYSTEM=="block", KERNEL=="*[0-9]*",
> > > ENV{ID_FS_USAGE}=="filesystem", TAG+="systemd",
> > > ENV{SYSTEMD_WANTS}+="start-standalone-mender-deployment@media-$name.service",
> > > RUN{program}+="/usr/bin/systemd-mount --no-block --automount=no
> > > --options=ro --collect $devnode /media/$name"
> > > ```
> > >
> > > And here's the systemd service:
> > > It is templated and gets instantiated with "media-sdb1". It therefore has
> > > an "After=media-sdb1.mount". I suspect Systemd-udevd executes the
> > > ENV{SYSTEMD_WANTS} part before the RUN{program} part. Hence,
> > > "media-sdb1.mount" doesn't yet exist when the service gets started, as it
> > > gets created a tad later by systemd-mount.
> > >
> > > ```
> > > [Unit]
> > > Description=Start standalone Mender deployment (%i)
> > > After=%i.mount
> > >
> > > [Service]
> > > Type=oneshot
> > > Restart=no
> > > ExecStart=/bin/sh /usr/bin/start-standalone-mender-deployment.sh /%I
> > > ```
> > >
> ...
> >
> > Hmm ... if systemd-mount --property accepts Wants and Before, your
> > mount unit could pull in your service unit. I cannot test right now.
> >
>
> Yes, this seems to work, so in principle
>
> RUN{program}+="/usr/bin/systemd-mount --no-block --automount=no
> --options=ro --collect --property
> Wants=start-standalone-mender-deployment@media-$name.service $devnode
> /media/$name"
>
> is possible. Unfortunately this starts unit even if mount fails and
> systemd-mount does not accept RequiredBy property". It is still
> possible to add Requires to service itself.
>
> [Unit]
> Description=Start standalone Mender deployment (%i)
> After=%i.mount
> Requires=%i.mount
>
> This will fail the service start job if the mount job fails.
>
> Wants on mount unit pulls in service, so we are guaranteed to always
> have both start jobs - for mount and for service and dependencies are
> observed.
>
I was unaware of the --property option of systemd-mount. It seems to be exactly
what I was looking for.
Thank you!
Unfortunately, while testing, I encountered problems with systemd-mount.
Sporadically, `systemd-mount /dev/sdb1 /media/sdb1` results in the following:
```
$ journalctl -fu systemd-udevd -u media-sdb1.mount -u dev-sdb1.device -u
systemd-fsck@dev-sdb1.service
15:55:46 systemd[1]: media-sdb1.mount: Failed to open
/run/systemd/transient/media-sdb1.mount: No such file or directory
15:56:46 systemd-udevd[57294]: sdb1: Spawned process '/usr/bin/systemd-mount
/dev/sdb1 /media/sdb1' [57295] is taking longer than 59s to complete
15:56:46 systemd-udevd[3019]: sdb1: Worker [57294] processing SEQNUM=6665 is
taking a long time
15:57:16 systemd[1]: dev-sdb1.device: Job dev-sdb1.device/start timed out.
15:57:16 systemd[1]: Timed out waiting for device /dev/sdb1.
15:57:16 systemd[1]: Dependency failed for /media/sdb1.
15:57:16 systemd[1]: media-sdb1.mount: Job media-sdb1.mount/start failed with
result 'dependency'.
15:57:16 systemd[1]: Dependency failed for File System Check on /dev/sdb1.
15:57:16 systemd[1]: systemd-fsck@dev-sdb1.service: Job
systemd-fsck@dev-sdb1.service/start failed with result 'dependency'.
15:57:16 systemd[1]: dev-sdb1.device: Job dev-sdb1.device/start failed with
result 'timeout'.
15:57:16 systemd-udevd[57294]: sdb1: Process '/usr/bin/systemd-mount /dev/sdb1
/media/sdb1' failed with exit code 1.
```
(Removed date and hostname for brevity.)
While mounting, I had `watch ls /run/systemd/transient/` running, and could see
that `media-sdb1.mount` pops into existence immediately when invoking
systemd-mount. So whatever tries to access misses it just.
Following to note:
* In the example above, systemd-mount got invoked from the following udev rule:
```
ACTION=="add", SUBSYSTEMS=="usb", SUBSYSTEM=="block", KERNEL=="*[0-9]*",
ENV{ID_FS_USAGE}=="filesystem", RUN{program}+="/usr/bin/systemd-mount $devnode
/media/$name"
```
* I triggered the rule with `udevadm trigger --verbose --action=add /dev/sdb`,
and did --action=remove before triggering again.
* When invoking from the shell, journalctl logs the same. (Minus the
systemd-udevd lines obviously.)
* `/bin/mount /dev/sdb1 /media/sdb1` works always
This whole things seems very flaky, but there seems to be a pattern, as crazy
as that may sound: Triggerung udev rule repeatedly results in the same outcome
(mount working or not); same with invoking manually on shell. But the two are
unrelated. At first it even seemed mounting from the rule ALWAYS fails and from
the shell ALWAYS works, but then I started to observe just a few cases which
proved me wrong. Now it doesn't work anymore either way. That said, yesterday I
had a shell script running which was triggering a similar udev rule repeatadly
~900 times, and mounting worked every single time.
I've got systemd 244 (244.3+) running. The di
