Re: [systemd-devel] Prerequisites for systemd.volatile=yes
Hi All, Any inputs on this? -- Shedi On Mon, Apr 15, 2024 at 7:15 PM Shreenidhi Shedi < shreenidhi.sh...@broadcom.com> wrote: > Hi All, > > I'm trying to use volatile root feature for the first time. > > This is my /etc/fstab: > ``` > #system mnt-pt type options dump fsck > PARTUUID=ad7ab716-2c0a-4dbe-9a28-06dc8bd0383b / ext4 > defaults,barrier,noatime,data=ordered 1 1 > ``` > > And systemd grub configs are: > systemd_cmdline=net.ifnames=0 plymouth.enable=0 > systemd.unified_cgroup_hierarchy=yes systemd.volatile=yes > > Finally, kernel command is: > BOOT_IMAGE=/vmlinuz-6.1.83-1.ph5 > root=PARTUUID=ad7ab716-2c0a-4dbe-9a28-06dc8bd0383b init=/lib/systemd/systemd > ro loglevel=3 quiet net.ifnames=0 plymouth.enable=0 > systemd.unified_cgroup_hierarchy=yes systemd.volatile=yes > > And I regenerated initrd using `mkinitrd` > > But when I rebooted my vm, it is going to emergency shell and shows > /run/initramfs/rdsosreport.txt and I'm not able to get into emergency shell > either, it just keeps looping in press Ctrl-D or enter root password prompt > and entering root password or pressing Ctrl-D just prompts the same thing > again. > > Can someone assist me on what are the prerequisites for enabling volatile > root? > > - Kernel configs to be enabled > - File system types supported > - Kernel command line args needed > > If someone can provide a step by step procedure on how to see this feature > in action, it would really help. > > -- > Shedi >
[systemd-devel] Prerequisites for systemd.volatile=yes
Hi All, I'm trying to use volatile root feature for the first time. This is my /etc/fstab: ``` #system mnt-pt type options dump fsck PARTUUID=ad7ab716-2c0a-4dbe-9a28-06dc8bd0383b / ext4 defaults,barrier,noatime,data=ordered 1 1 ``` And systemd grub configs are: systemd_cmdline=net.ifnames=0 plymouth.enable=0 systemd.unified_cgroup_hierarchy=yes systemd.volatile=yes Finally, kernel command is: BOOT_IMAGE=/vmlinuz-6.1.83-1.ph5 root=PARTUUID=ad7ab716-2c0a-4dbe-9a28-06dc8bd0383b init=/lib/systemd/systemd ro loglevel=3 quiet net.ifnames=0 plymouth.enable=0 systemd.unified_cgroup_hierarchy=yes systemd.volatile=yes And I regenerated initrd using `mkinitrd` But when I rebooted my vm, it is going to emergency shell and shows /run/initramfs/rdsosreport.txt and I'm not able to get into emergency shell either, it just keeps looping in press Ctrl-D or enter root password prompt and entering root password or pressing Ctrl-D just prompts the same thing again. Can someone assist me on what are the prerequisites for enabling volatile root? - Kernel configs to be enabled - File system types supported - Kernel command line args needed If someone can provide a step by step procedure on how to see this feature in action, it would really help. -- Shedi
[systemd-devel] Restarting dbus service makes system unstable
Hi All, I tried this on Fedora 39 so anyone can reproduce this at their end I guess. Steps: 1. systemctl restart dbus 2. Try to start a new ssh session or invoke a reboot command It will take 25 seconds to finish and if we restart systemd-logind, system becomes stable. busctl --list shows logind as activatable. Is this a known issue? I tried the same on a systemd with systemd v247.13 and it doesn't happen there. With systemd v253.12 and in v254.9 (fedora's) this is reproducible 100%. -- Shedi
Re: [systemd-devel] Query on sshd.socket sshd.service approaches
On Thu, Mar 7, 2024 at 1:24 PM Shreenidhi Shedi < shreenidhi.sh...@broadcom.com> wrote: > On Wed, Mar 6, 2024 at 8:57 PM Lennart Poettering > wrote: > >> On Mi, 06.03.24 14:44, Shreenidhi Shedi (shreenidhi.sh...@broadcom.com) >> wrote: >> >> > > Lennart Poettering, Berlin >> > >> > Thanks a lot for the responses Andrei, Poettering . >> > We took it from blfs in PhotonOS. >> > >> https://www.linuxfromscratch.org/blfs/view/11.3-systemd/introduction/systemd-units.html >> > We need to do some more work on these unit files. >> >> But that tarball actually contains a correct sshd -i line that >> includes the "-" that makes the return values to be ignored as it >> should. Hence if your distro didn't do this even though it imported >> this from LFS, then it's your distro that broke that... >> >> Lennart >> >> -- >> Lennart Poettering, Berlin >> > > I'm not sure which file you are referring to. > Please check this one blfs-systemd-units-20220720/blfs/units/sshdat.service > > -- > Shedi > Sorry, my bad. I referred an older version of this tarball. https://www.linuxfromscratch.org/blfs/downloads/11.3-systemd/blfs-systemd-units-20220720.tar.xz I see that in the latest revisions, it's fixed. https://www.linuxfromscratch.org/blfs/downloads/systemd/ -- Shedi
Re: [systemd-devel] Query on sshd.socket sshd.service approaches
On Wed, Mar 6, 2024 at 8:57 PM Lennart Poettering wrote: > On Mi, 06.03.24 14:44, Shreenidhi Shedi (shreenidhi.sh...@broadcom.com) > wrote: > > > > Lennart Poettering, Berlin > > > > Thanks a lot for the responses Andrei, Poettering . > > We took it from blfs in PhotonOS. > > > https://www.linuxfromscratch.org/blfs/view/11.3-systemd/introduction/systemd-units.html > > We need to do some more work on these unit files. > > But that tarball actually contains a correct sshd -i line that > includes the "-" that makes the return values to be ignored as it > should. Hence if your distro didn't do this even though it imported > this from LFS, then it's your distro that broke that... > > Lennart > > -- > Lennart Poettering, Berlin > I'm not sure which file you are referring to. Please check this one blfs-systemd-units-20220720/blfs/units/sshdat.service -- Shedi
Re: [systemd-devel] Query on sshd.socket sshd.service approaches
On Wed, Mar 6, 2024 at 2:01 PM Lennart Poettering wrote: > On Mi, 06.03.24 11:11, Shreenidhi Shedi (shreenidhi.sh...@broadcom.com) > wrote: > > > Hi All, > > > > What is the rationale behind using sshd.socket other than not keeping > sshd > > daemon running always and reducing memory consumption? > > Note that there are two distinct modes to running sshd via socket > activation: the per-connection mode (using sshd's native inetd mode), > where there's a separate instance forked off by systemd for each > connection, and the a mode where systemd just binds the socket, but > it's served by a single instance. The latter is only supported via an > out-of-tree patch afaik though, which at least debian/ubuntu ship: > > > https://salsa.debian.org/ssh-team/openssh/-/commit/7fa10262be3c7d9fd2fca9c9710ac4ef3f788b08 > > Unless you have a gazillion of connections coming in every second I'd > probably just use the per-connection inetd mode, simply because it's > supported upstream. Would be great of course if openssh would just add > support for the single-instance mode in upstream too, but as I > understand ssh upstream is a bit special, and doesn't want to play > ball on this. > > To summarize the benefits of each mode: > > 1. Traditional mode (i.e. no socket activation) >+ connections are served immediately, minimal latency during > connection setup >- takes up resources all the time, even if not used > > 2. Per-connection socket activation mode >+ takes up almost no resources when not used >+ zero state shared between connections >+ robust updates: socket stays connectible throughout updates >+ robust towards failures in sshd: the bad instance dies, but sshd > stays connectible in general >+ resource accounting/enforcement separate for each connection >- slightly bigger latency for each connection coming in >- slightly more resources being used if many connections are > established in parallel, since each will get a whole sshd > instance of its own. > > 3. Single-instance socket activation mode >+ takes up almost no resources when not used >+ robust updates: socket stays connectible throughout updates > > > With sshd.socket, systemd does a fork/exec on each connection which is > > expensive and with the sshd.service approach server will just connect > with > > the client which is less expensive and faster compared to > > sshd.socket. > > The question of course is how many SSH instances you serve every > minute. My educated guess is that most SSH installations have a use > pattern that's more on the "sporadic use" side of things. There are > certainly heavy use scenarios though (e.g. let's say you are github > and server git via sshd). I'd suggests to distros to default to mode > 2, and alternatively support mode 3 if possible (and mode 1 if they > don#t want to patch the support for mode 3 in) > > > And if there are issues in unit files like in > > https://github.com/systemd/systemd/issues/29897 it will make the system > > unusable. > > Did any distro ship a unit file like that? That was clearly a buggy > (local?) unit file, I am not aware of any big distro shipping such a > unit file. > > Lennart > > -- > Lennart Poettering, Berlin > Thanks a lot for the responses Andrei, Poettering . We took it from blfs in PhotonOS. https://www.linuxfromscratch.org/blfs/view/11.3-systemd/introduction/systemd-units.html We need to do some more work on these unit files. -- Shedi
[systemd-devel] Query on sshd.socket sshd.service approaches
Hi All, What is the rationale behind using sshd.socket other than not keeping sshd daemon running always and reducing memory consumption? With sshd.socket, systemd does a fork/exec on each connection which is expensive and with the sshd.service approach server will just connect with the client which is less expensive and faster compared to sshd.socket. And if there are issues in unit files like in https://github.com/systemd/systemd/issues/29897 it will make the system unusable. I want to understand this better and know more on the history behind these design decisions. Thanks. -- Shedi
