Re: [systemd-devel] Prefix delegation and IPv6 subnetting
This issue for ISC's Kea DHCPv6 server has some useful insights into what's required of a program that manages prefix delegation. See the long comment from Tomek Mrugalski 2 years ago. https://gitlab.isc.org/isc-projects/kea/-/issues/856
[systemd-devel] Regarding service rate limiting (systemd 237)
Hello, I am on Ubuntu 18.04 (systemd version 237), I have been trying to get service rate limiting to work, but not getting it right! I checked/tested many examples with the same directives that I use in my service files, they all work well (for e.g.) cat < /usr/local/bin/myservice.sh #!/usr/bin/env bash sleep $(( $RANDOM % 15 )) exit 0 EOF cat < /etc/systemd/system/my.service [Unit] StartLimitBurst=5 StartLimitIntervalSec=90 [Service] ExecStart=/bin/bash /usr/local/bin/myservice.sh RestartSec=5 Restart=always EOF but somehow only with the services that I am trying to rate-limit (C,unix daemons), it doesn't work! :( I enabled systemd Loglevel=debug but still not getting any clues, the only odd message I see is: systemd[1]: my-cdaemon.service: Unknown serialization key: ref-gid systemd[1]: my-cdaemon.service: Changed dead -> running systemd[1]: my-cdaemon.service: Unknown serialization key: ref-gid Is this something to worry about ? Another difference from conventional service start is, the actual service is invoked like: /bin/bash -c 'exec /opt/org/bin/my-cdaemon $OPTS >> /var/log/org/my-cdaemon.log 2>&1' This should be OK? I just want to make sure that the disk is not filled with core files (the daemon dumps pretty huge core files), hence [trying] to limit it to 5 restarts, but it keeps restarting forever :( systemd[1]: my-cdaemon.service: Trying to enqueue job my-cdaemon.service/restart/replace systemd[1]: my-cdaemon.service: Installed new job my-cdaemon.service/restart as 107718 systemd[1]: my-cdaemon.service: Enqueued job my-cdaemon.service/restart as 107718 systemd[1]: my-cdaemon.service: Scheduled restart job, restart counter is at 113. < systemd[1]: my-cdaemon.service: Changed auto-restart -> dead systemd[1]: my-cdaemon.service: Job my-cdaemon.service/restart finished, result=done I tried to factor the _time taken to write the core file_ as well, in `StartLimitIntervalSec', still no luck! How can I troubleshoot this further ? Is there any way to "know" the internal state that systemd is tracking for this daemon _after 5 restarts_ ? -- Ani
Re: [systemd-devel] Antw: [EXT] Re: [systemd‑devel] Running actual systemd‑based distribution image in systemd‑nspawn
On Mo, 11.07.22 13:57, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > > That said: I strongly recommend that distros ship empty /etc/fstab by > > default, and rely on GPT partition auto discovery > > (i.e. systemd‑gpt‑auto‑generator) to mount everything, and only depart > > from that if there's a strong reason to, i.e. default mount options > > don't work, or external block device referenced or so. > > What if you have multiple operating systems in various partitions on one > disk? > /etc/fstab absolutely makes sense See boot loader spec about that. Basically, the assumption that for things like swap, /var/tmp or /home it's OK or even a good thing if shared between OSes. The major execption is /var/ itself, which is per OS installation and should not be shared between multiple installations. The boot loader spec hence by default will only auto-mount /var/ partitions only if the GPT partition uuid of that is hashed from the machine id. But there are two distinct concepts here: 1. tag your partitions properly by type uuid. This is always a good idea, and makes nspawn just work. and all other tools that recognize partition type uuids, i.e. all the --image= switches systemd tools have, and so on. 2. actually ship an empty /etc/fstab and rely solely on gpt auto discovery. i'd always do that whereever possible (i.e. any OS where multibot does't matter, i.e. appliances, images for VMs/nspawn, cloud stuff, servers). i.e. concept 1 should always be done. If you then also adopt concept 2 is up to you. You can, but you don't have to. Lennart -- Lennart Poettering, Berlin
[systemd-devel] Antw: [EXT] Re: [systemd‑devel] Running actual systemd‑based distribution image in systemd‑nspawn
>>> Lennart Poettering schrieb am 30.06.2022 um 22:23 in Nachricht : > On Do, 16.06.22 09:27, Colin Guthrie (gm...@colin.guthr.ie) wrote: > >> Andrei Borzenkov wrote on 15/06/2022 16:56: >> > I tried it (loop mounting qemu image): >> > >> > systemd‑nspawn ‑D ./hd0 ‑b >> > >> > and it failed miserably with "Timeout waiting for device >> > dev‑disk‑by...". Which is not surprising as there are no device units >> > inside of container (it stops in single user allowing me to use sysctl >> > ‑t device). >> > >> > Is it supposed to work at all? Even if I bind mount /dev/disk it does >> > not help as systemd does not care whether device is actually present or > not. >> >> I've not tried "booting" a real install inside nspawn before (just images >> installed by mkosi mostly), but could this just be a by‑product of it trying >> to do what /etc/fstab (or other mount units) say to do? >> >> Can you try something like: >> >> touch blank >> systemd‑nspawn ‑‑bind‑ro=./blank:/etc/fstab ‑D ./hd0 ‑b > > This should not be necessary, as systemd‑fstab‑generator actually > ignores all /etc/fstab entries referencing block devices. See this: > > https://github.com/systemd/systemd/blob/main/src/fstab‑generator/fstab‑generat > or.c#L602 > > (i.e. container managers such as nspawn should mount /sys/ read‑only, > which is indication to container payloads that device management > should not be done by them but is done somewhere else. This is used as > check whether to ignore the fstab entries that look like device patjs, > i.e. start with /dev). > > How precisely does the offending fstab line look like for you? > Normally it should be ignored just like that. If it is not ignored, > this looks like a bug. > >> to override the /etc/fstab (there may be other more elegant ways to disable >> fstab processing!) and see if that helps? > > No need. Should happen automatically. > > That said: I strongly recommend that distros ship empty /etc/fstab by > default, and rely on GPT partition auto discovery > (i.e. systemd‑gpt‑auto‑generator) to mount everything, and only depart > from that if there's a strong reason to, i.e. default mount options > don't work, or external block device referenced or so. What if you have multiple operating systems in various partitions on one disk? /etc/fstab absolutely makes sense Regards, Ulrich
