[systemd-devel] correct usage for file-only & (sub)dir-only shell globs in unit tmpfiles?
I want to chmod all files and dirs/subdirs in a tree using tmpfiles.
Starting with an example tree
tree -pF /home/test/TEST
/home/test/TEST
└── [dr] topdir/
├── [-r] A.txt
└── [dr] subdir1/
├── [-r] B.txt
└── [dr] subdir2/
└── [-r] C.txt
I want to chmod
all files -> 0640
all dirs -> 0750
i.e., ending up with
/home/test/TEST
└── [drwxr-x---] topdir/
├── [-rw-r-] A.txt
└── [drwxr-x---] subdir1/
├── [-rw-r-] B.txt
└── [drwxr-x---] subdir2/
└── [-rw-r-] C.txt
for this, it seems shell globs are appropriate.
but, with
/etc/tmpfiles.d/test.conf
(1) Z /home/test/TEST/{.,**/} 0750 nobody nobody -
(2A)Z /home/test/TEST/** 0640 nobody nobody -
or
(2B)Z /home/test/TEST/{**,!.,!**/} 0640 nobody nobody -
, where the intention was that shell glob (1) matches only dirs/subdirs, and
glob (2A) or (2B) matches files,
after exec of
systemd-tmpfiles --create /etc/tmpfiles.d/dovecot.conf
I end up, instead, with
tree -pF /home/test/TEST
/home/test/TEST
└── [drw-r-] topdir/
├── [-rw-r-] A.txt
└── [drw-r-] subdir1/
├── [-rw-r-] B.txt
└── [drw-r-] subdir2/
└── [-rw-r-] C.txt
... with all my intended 0750 exec'able dir modes are overwritten with
intended-for-files modes.
either my globs are wrong &/or I'm bumping into recursion conflicts with "Z" in
tmpfiles.
What's the right usage/syntax in a tmpfile to efficiently/correctly get that^
done?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] workaround for systemd-networkd-wait-online boot fail/delay on systems with bridge for v234? (fix @ systemd/issues/2154 requires v>242)
On 7/11/20 11:05 PM, Paul Menzel wrote: > If systemd is still the same, your distribution upgrade wasn’t relevant to > the issue at hand, was it? no, I didn't state that it was. What's relevant is that I followed the suggested workaround made to me, and there was no observed effect. It was simply mentioned here on the off-chance that @ distro-upgrade some backport/patch/fix might have been implemented. Clearly it wasn't. > The upstream project only supports the latest two versions of systemd, which > currently are 244 and 245. Please report your issues to openSUSE. Lennart was kind enough to comment previously. I'm asking Lennart for additional comment on his recommendation ... made here, so asked here. > Please report your issues to openSUSE. as stated in my OP, it already has been. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] workaround for systemd-networkd-wait-online boot fail/delay on systems with bridge for v234? (fix @ systemd/issues/2154 requires v>242)
On 6/16/20 1:35 AM, Lennart Poettering wrote: > On Sa, 30.05.20 18:02, PGNet Dev (pgnet@gmail.com) wrote: > >> IS there a backport of this^^ fix available for v234 that popped up in >> the meantime? >> >> If not, as is likely, is there a "safe" workaround for quieting the >> fail, and rm'ing the associated boot delay? Is rm'ing either the "Also=" or >> "WantedBy=" a reasonable band-aid? >> >> Or, some other approach? > > You could use RequiredForOnline= in the bridge's .network file to mark > it as irrelevant for systemd-network-wait-online. > > Lennart > > -- > Lennart Poettering, Berlin On my current machine, just upgraded to new OS version (still same distro -- for the moment) I've, networkctl IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 enp3s0 ether no-carrier configuring 3 enp5s0 ether routableconfigured infc #3 is active; intfc #2 is unused I added to each cd /etc/systemd/network grep Link -A1 * 20-enp3s0.network:[Link] 20-enp3s0.network-RequiredForOnline=no -- 20-enp5s0.network:[Link] 20-enp5s0.network-RequiredForOnline=no and rebooted. still, there's a 2min delay on startup systemd-analyze blame | head 2min 284ms systemd-networkd-wait-online.service 5.803s dkms.service 5.409s rc-local.service 4.270s mariadb-custom.service 3.952s after-local.service 3.647s udisks2.service 2.985s rpcbind.service 2.936s mcelog.service 2.901s ca-certificates.service 2.878s smartd.service in dmesg, dmesg | grep wait-online -A1 -B1 [ 129.299191] systemd[1]: Started update geoipdb service. [ 130.961418] systemd-networkd-wait-online[1664]: Event loop failed: Connection timed out [ 130.971019] systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE [ 130.971276] systemd[1]: Failed to start Wait for Network to be Configured. [ 130.974180] systemd[1]: systemd-networkd-wait-online.service: Unit entered failed state. [ 130.974187] systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'. [ 130.974266] systemd[1]: Reached target Network is Online. other than the two interfaces I _do_ have -- and have set [Link] RequiredForOnline=no for, what's possibly _still_ causing this delay? this^ is, as before, with rpm -qa | grep ^systemd-2 systemd-234-lp152.30.1.x86_64 switching back to non-systemd-networkd network stack eliminates any such delay. not surprising, given the bug -- and certainly not ideal. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] workaround for systemd-networkd-wait-online boot fail/delay on systems with bridge for v234? (fix @ systemd/issues/2154 requires v>242)
I've switched from distro networking stack (wicked) to systemd-network; generally, what a relief! The distro (opensuse leap 15.1) has 'old' systemd -- v234 As packaged, 'systemd-network.service' has "Also=systemd-networkd-wait-online.service". & 'systemd-networkd-wait-online.service' has "WantedBy=network-online.target" A number of my services depend on 'network-online.target'. All this^ is to say -- if 'network-online.target' is used, 'systemd-networkd-wait-online.service' gets launched. My box ALSO has a bridge defined. Which causes me to hit "systemd-networkd-wait-online fails with bridged interfaces" https://github.com/systemd/systemd/issues/2154 on boot, [ 151.868637] systemd-networkd-wait-online[1394]: Event loop failed: Connection timed out [ 151.884034] systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE [ 151.885593] systemd[1]: Failed to start Wait for Network to be Configured. [ 151.885714] systemd[1]: systemd-networkd-wait-online.service: Unit entered failed state. [ 151.885741] systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'. which causes significant delay systemd-analyze critical-chain multi-user.target @2min 50.841s └─... └─network-online.target @2min 19.876s └─network.target @19.712s └─systemd-networkd.service @19.268s +409ms └─network-pre.target @19.249s └─... The solution @bug is -- upgrade to systemd v242. On this distro, upstream refuses to upgrade systemd; apparently for them its 'non trivial' and they can't be bothered. AND, they've a new 'stable' version coming out AnyDayNow(tm), Leap 15.2, for which apparently systemd will REMAIN at broken-like-this^^ v234. So *my* solution has been to switch distros. NOT just for this^^ reason, but it was the last straw ... ~ 600 machines have finished migrating to other distros with newer systemd installs that avoid this problem. BUT -- I'm left with a few boxes that I can't move for awhile. So ... IS there a backport of this^^ fix available for v234 that popped up in the meantime? If not, as is likely, is there a "safe" workaround for quieting the fail, and rm'ing the associated boot delay? Is rm'ing either the "Also=" or "WantedBy=" a reasonable band-aid? Or, some other approach? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-networkd IP assignments for wla/usb devs are ignored; using same IP as local eth lan ?
I'm migrating a linux box to systemd-network use, uname -rm 5.6.3-24.ge840c7b-default x86_64 rpm -qa | grep ^systemd-2 systemd-234-lp151.26.13.1.x86_64 systemctl list-unit-files | grep systemd-net systemd-networkd-wait-online.serviceenabled systemd-networkd.serviceenabled systemd-networkd.socket enabled I've got two ethernet ports, and two USB wifi dongles. I've config'd /etc/systemd/network/20-enp2s0.network [Match] Name=enp2s0 [Network] DHCP=ipv4 DefaultRouteOnDevice=true IPForward=0 LinkLocalAddressing=ipv4 IPv6AcceptRA=0 /etc/systemd/network/20-enp3s0.network [Match] Name=enp3s0 [Network] Address=172.30.11.51/22 IPForward=1 IPv6AcceptRA=0 /etc/systemd/network/21-wlp0s16u2u1.network [Match] Name=wlp0s16u2u1 [Network] Address=172.30.12.51/24 Gateway=172.30.12.51 IPForward=1 LinkLocalAddressing=ipv4 IPv6AcceptRA=0 /etc/systemd/network/21-wlp0s16u2u2.network [Match] Name=wlp0s16u2u2 [Network] Address=172.30.13.51/24 Gateway=172.30.13.51 IPForward=1 LinkLocalAddressing=ipv4 IPv6AcceptRA=0 the IPs/gateways assigned are identical to what's running on the system, using distro-native networking, prior to the switch to systemd-networkd on boot enp2s0 is correctly config'd from upstream dhcp. next, enp3s0 my lan-facing intfc, is up correctly too enp3s0: flags=4163 mtu 1500 inet 172.30.11.51 netmask 255.255.252.0 broadcast 172.30.11.255 ... no prob with loopback, lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 ... BUT, the two wlan intfcs ARE up, but configured with the SAME ip/mask as the local lan, NOT the one spec'd in the config wlp0s16u2u1: flags=4163 mtu 1500 inet 172.30.11.51 netmask 255.255.252.0 broadcast 172.30.11.255 ... wlp0s16u2u2: flags=4163 mtu 1500 inet 172.30.11.51 netmask 255.255.252.0 broadcast 172.30.11.255 ... clearly, others are config'ing wlans. what needs to be changed/added in my config to get those wlan IPs correctly allocated? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd v228 errors: "Failed to enqueue exit.target job: Transaction contains conflicting jobs 'start' and 'stop'" ?
I'm booting a systemctl --version systemd 228 +PAM +AUDIT +SELINUX -IMA +APPARMOR -SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN OS instance. Atm, it's a Xen DomU vm guest. It's a DIY-build instance of current systemd for a stable distro release; @ distro has no apparent interest in supporting it. Despite that, I'm trying to get it working and cleaned up for my own use. On boot, I see these in logs dmesg ... [ 374.429270] systemd[1617]: Failed to enqueue exit.target job: Transaction contains conflicting jobs 'start' and 'stop' for shutdown.target. Probably contradicting requirement dependencies configured. [ 698.686714] systemd[1834]: Failed to enqueue exit.target job: Transaction contains conflicting jobs 'stop' and 'start' for exit.target. Probably contradicting requirement dependencies configured. [ 698.729596] systemd[1848]: Failed to enqueue exit.target job: Transaction contains conflicting jobs 'stop' and 'start' for systemd-exit.service. Probably contradicting requirement dependencies configured. [ 698.767659] systemd[1861]: Failed to enqueue exit.target job: Transaction contains conflicting jobs 'stop' and 'start' for shutdown.target. Probably contradicting requirement dependencies configured. [ 698.801234] systemd[1871]: Failed to enqueue exit.target job: Transaction contains conflicting jobs 'stop' and 'start' for systemd-exit.service. Probably contradicting requirement dependencies configured. [ 698.843302] systemd[1884]: Failed to enqueue exit.target job: Transaction contains conflicting jobs 'stop' and 'start' for systemd-exit.service. Probably contradicting requirement dependencies configured. ... Currently, locate exit.target shutdown.target systemd-exit.service /usr/lib/systemd/system/shutdown.target /usr/lib/systemd/system/shutdown.target.wants /usr/lib/systemd/system/shutdown.target.wants/dracut-shutdown.service /usr/lib/systemd/user/exit.target /usr/lib/systemd/user/shutdown.target /usr/lib/systemd/user/systemd-exit.service rpm -q --whatprovides $( locate exit.target shutdown.target systemd-exit.service ) systemd-228-18.1.x86_64 systemd-228-18.1.x86_64 dracut-037-68.1.x86_64 systemd-228-18.1.x86_64 systemd-228-18.1.x86_64 systemd-228-18.1.x86_64 Where cat /usr/lib/systemd/user/exit.target [Unit] Description=Exit the Session Documentation=man:systemd.special(7) DefaultDependencies=no Requires=systemd-exit.service After=systemd-exit.service AllowIsolate=yes cat /usr/lib/systemd/system/shutdown.target [Unit] Description=Shutdown Documentation=man:systemd.special(7) DefaultDependencies=no RefuseManualStart=yes cat /usr/lib/systemd/system/shutdown.target.wants/dracut-shutdown.service [Unit] Description=Restore /run/initramfs Documentation=man:dracut-shutdown.service(8) After=getty@tty1.service display-manager.service Before=systemd-reboot.service shutdown.target DefaultDependencies=no ConditionPathExists=/run/initramfs/.need_shutdown ConditionPathExists=!/run/initramfs/bin/sh [Service] ExecStart=-/usr/lib/dracut/dracut-initramfs-restore Type=oneshot RemainAfterExit=yes cat /usr/lib/systemd/user/shutdown.target [Unit] Description=Shutdown Documentation=man:systemd.special(7) DefaultDependencies=no RefuseManualStart=yes cat /usr/lib/systemd/user/systemd-exit.service [Unit] Description=Exit the Session Documentation=man:systemd.special(7) DefaultDependencies=no Requires=shutdown.target After=shutdown.target multi-user.target [Service] Type=oneshot WorkingDirectory=/ ExecStart=/usr/bin/kill -s SIGRTMIN+24 $MANAGERPID The deps are a bit convoluted at 1st look. What in that config's causing the Transaction contains conflicting jobs 'start' and 'stop' fails? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
