[systemd-devel] network config breaks when starting a nspawn container
Hi, systemd-networkd creates a bridge 'br0': $ cat /etc/systemd/network/30-br0.network [Match] Name=br0 [Network] DHCP=ipv4 Domains=~. The bridge has one slave 'bond0' by default. The bond device is used to aggregate my ethernet card and my wifi card (configured by NM). systemd-resolved is also used. Every thing works until I start a container 'c1' which should connect to br0: $ cat /etc/systemd/nspawn/c1.nspawn [Exec] PrivateUsers=off [Network] Bridge=br0 A few seconds later, the bridge lost its IP, no more route. I can see this in the journal: Jan 27 06:44:40 h200 systemd[1]: Starting Container c1... Jan 27 06:44:40 h200 systemd-udevd[8148]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable. Jan 27 06:44:40 h200 systemd-networkd[568]: vb-c1: Link UP Jan 27 06:44:40 h200 kernel: br0: port 2(vb-c1) entered blocking state Jan 27 06:44:40 h200 kernel: br0: port 2(vb-c1) entered disabled state Jan 27 06:44:40 h200 kernel: device vb-c1 entered promiscuous mode Jan 27 06:44:40 h200 kernel: br0: port 2(vb-c1) entered blocking state Jan 27 06:44:40 h200 kernel: br0: port 2(vb-c1) entered forwarding state Jan 27 06:44:40 h200 kernel: br0: port 2(vb-c1) entered disabled state Jan 27 06:44:40 h200 systemd-udevd[8148]: Using default interface naming scheme 'v238'. Jan 27 06:44:40 h200 systemd-networkd[568]: br0: DHCP lease lost Jan 27 06:44:40 h200 NetworkManager[8437]: [1643262280.6795] manager: (vb-c1): new Veth device (/org/freedesktop/NetworkManager/Devices/11) Jan 27 06:44:40 h200 systemd-machined[28861]: New machine c1. Jan 27 06:44:40 h200 systemd[1]: Started Container c1. [...] Jan 27 06:44:42 h200 systemd-networkd[568]: vb-c1: Gained IPv6LL Jan 27 06:44:44 h200 systemd-resolved[913]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server fd0f:ee:b0::1. Jan 27 06:44:47 h200 systemd-resolved[913]: Using degraded feature set TCP instead of UDP for DNS server fd0f:ee:b0::1. Jan 27 06:44:57 h200 systemd-resolved[913]: Using degraded feature set UDP instead of TCP for DNS server fd0f:ee:b0::1. Jan 27 06:45:00 h200 systemd-resolved[913]: Using degraded feature set TCP instead of UDP for DNS server fd0f:ee:b0::1. If I stop the container then network is back. This happens with systemd v246. Could anyody help me fixing this issue ? Thank you. -- Francis
Re: [systemd-devel] systemd killing processes on monitor wakeup?
Does anyone have any tips for debugging this or getting more information? Should I create an issue for this? On Sun, Jan 23, 2022 at 3:43 PM Raman Gupta wrote: > (A variation of this message was originally sent to fedora-users) > > I have a couple processes that have been consistently dying every time I > wake up my monitors after the system has been idle. One is Slack Desktop > and the other is IntelliJ IDEA. > > I used an eBPF program (killsnoop.py at > https://github.com/iovisor/bcc/blob/master/tools/killsnoop.py) to trace > where the signal to shut down these processes was coming from, and it > appears that systemd is sending pretty much every active process signal 15 > and then 18. > > TIME PIDCOMM SIG TPID RESULT > ... on monitor wakeup ... > 12:16:58 2551 systemd 15 2938613 0 > 12:16:58 2551 systemd 18 2938613 0 > 12:16:58 2551 systemd 15 2938814 0 > 12:16:58 2551 systemd 18 2938814 0 > 12:16:58 2551 systemd 15 2938832 0 > 12:16:58 2551 systemd 18 2938832 0 > 12:16:58 2551 systemd 15 2938978 0 > 12:16:58 2551 systemd 18 2938978 0 > 12:16:58 2551 systemd 15 2939432 0 > 12:16:58 2551 systemd 18 2939432 0 > 12:16:58 2551 systemd 15 2939899 0 > 12:16:58 2551 systemd 18 2939899 0 > 12:16:58 2551 systemd 15 2942192 0 > 12:16:58 2551 systemd 18 2942192 0 > ... > > Process 2551 is the PDF of the source of the signal according to > killsnoop, 15 and 18 are the signals being sent, and TPID is the target > PID, which among many others, does include my dying processes. Process 2551 > is indeed systemd, specifically the user process: > > raman 2551 1 0 Jan07 ?00:00:10 > /usr/lib/systemd/systemd --user > > This behavior is relatively new. What is going on here? I haven't found > any other reports of this behavior anywhere else. > > I'm using systemd-249.9-1.fc35 on Fedora 35. > > Regards, > Raman > >
Re: [systemd-devel] stacked extension not working
Way to go Luca! Thank you for informing. We still have great interest in portable services. On 2022-01-23, 4:45 PM, "Luca Boccassi" wrote: FYI, support for using directories with --extension has just been merged in main and will be available in v251. On Wed, 20 Oct 2021 at 16:15, Luca Boccassi wrote: > > No, it's only supported for images at the moment, as the documentation > says: > >--extension=PATH >Add an additional image PATH as an overlay on top of IMAGE > when attaching/detaching. This argument can >be specified multiple times, in which case the order in > which images are laid down follows the rules >specified in systemd.exec(5) for the ExtensionImages= > directive. The image(s) must contain an >extension-release file with metadata that matches what is > defined in the os-release of IMAGE. See: os- >release(5). > > The internal implementation of extensions is ExtensionImage= which as > the name says, it's for binary images. There's no ExtensionDirectory= > yet - no reason it can't there be one, just someone needs to implement > it. PRs welcome! > > On Wed, 2021-10-20 at 17:04 +0200, Umut Tezduyar Lindskog wrote: > > It indeed worked as squashfs image. Thanks for that. > > > > It is not working as a folder though (portablectl --runtime attach -- > > extension=./stackupper ./base stackupper) This stuff should work on > > folders too right? Should I open a ticket? > > > > Also, when it works, the upper stack shows as detached. Isn't that > > wrong too? Should I open a ticket? > > > > root@osboxes:/home/osboxes/Development# portablectl attach --runtime > > --extension $PWD/stackupper.raw $PWD/base.raw stackupper > > (Matching unit files with prefixes 'stackupper'.) > > Created directory /run/systemd/system.attached. > > Created directory /run/systemd/system.attached/stackupper.service.d. > > Written /run/systemd/system.attached/stackupper.service.d/20- > > portable.conf. > > Created symlink /run/systemd/system.attached/stackupper.service.d/10- > > profile.conf → > > /usr/lib/systemd/portable/profile/default/service.conf. > > Copied /run/systemd/system.attached/stackupper.service. > > Created symlink /run/portables/stackupper.raw → > > /home/osboxes/Development/stackupper.raw. > > Created symlink /run/portables/base.raw → > > /home/osboxes/Development/base.raw. > > root@osboxes:/home/osboxes/Development# portablectl list > > NAME TYPE RO CRTIME MTIME > > USAGE STATE > > base raw no Wed 2021-10-20 10:54:41 EDT Wed 2021-10-20 > > 10:54:41 EDT 920.0K attached-runtime > > stackupper raw no Wed 2021-10-20 10:54:57 EDT Wed 2021-10-20 > > 10:54:57 EDT 36.0K detached > > > > > > Thanks again > > Umut > > > > On Wed, Oct 20, 2021 at 12:01 AM Luca Boccassi > > wrote: > > > On Tue, 2021-10-19 at 16:09 +0200, Umut Tezduyar Lindskog wrote: > > > > Hi Luca, have you had time to help me out or do you think you > > > could > > > > help me > > > > out? Thanks in advance. > > > > > > Works fine for me with systemd 249.5: > > > > > > $ tar xf ~/Downloads/portable.tar > > > $ mksquashfs base/ base.raw > > > Parallel mksquashfs: Using 4 processors > > > Creating 4.0 filesystem on base.raw, block size 131072. > > > [== > > > =|] 23/23 100% > > > > > > Exportable Squashfs 4.0 filesystem, gzip compressed, data block > > > size 131072 > > > compressed data, compressed metadata, compressed fragments, > > > compressed xattrs, compressed ids > > > duplicates are removed > > > Filesystem size 918.80 Kbytes (0.90 Mbytes) > > > 39.83% of uncompressed filesystem size (2306.95 Kbytes) > > > Inode table size 359 bytes (0.35 Kbytes) > > > 35.69% of uncompressed inode table size (1006 bytes) > > > Directory table size 319 bytes (0.31 Kbytes) > > > 62.80% of uncompressed directory table size (508 bytes) > > > Number of duplicate files found 3 > > > Number of inodes 29 > > > Number of files 9 > > > Number of fragments 2 > > > Number of symbolic links 0 > > > Number of device nodes 0 > > > Number of fifo nodes 0 > > > Number of socket nodes 0 > > > Number of directories 20 > > > Number of ids (unique uids + gids) 1 > > > Number of uids 1 > > > luca (1000) > > > Number of gids 1 > > > luca (1000) > > > $ mksquashfs stackupper/ stackupper.raw > > > Parallel mksquashfs: Using 4 processors > > > Creating 4.0 filesystem on stackupper.raw, block size
