Re: [systemd-devel] consider dropping defrag of journals on btrfs
On Tue, Jan 5, 2021 at 10:04 AM Chris Murphy wrote: > > f27a386430cc7a27ebd06899d93310fb3bd4cee7 > journald: whenever we rotate a file, btrfs defrag it > > Since systemd-journald sets nodatacow on /var/log/journal the journals > don't really fragment much. I typically see 2-4 extents for the life > of the journal, depending on how many times it's grown, in what looks > like 8MiB increments. The defragment isn't really going to make any > improvement on that, at least not worth submitting it for additional > writes on SSD. While laptop and desktop SSD/NVMe can handle such a > small amount of extra writes with no meaningful impact to wear, it > probably does have an impact on much more low end flash like USB > sticks, eMMC, and SD Cards. So I figure, let's just drop the > defragmentation step entirely. > > Further, since they are nodatacow, they can't be submitted for > compression. There was a quasi-bug in Btrfs, now fixed, where > nodatacow files submitted for decompression were compressed. So we no > longer get that unintended benefit. This strengthens the case to just > drop the defragment step upon rotation, no other changes. > > What do you think? A better idea. Default behavior: journals are nodatacow and are not defragmented. If '/etc/tmpfiles.d/journal-nocow.conf ` exists, do the reverse. Journals are datacow, and files are defragmented (and compressed, if it's enabled). -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What exactly is multi-seat? -- questions about logind
On 21/01/26 11:45AM, Lennart Poettering wrote: > On Di, 26.01.21 01:43, Kian Kasad (k...@kasad.com) wrote: > > > Hi all, > > > > After reading the documentation on logind and multi-seat (specifically > > sd-login(3) and "Multi-Seat on Linux"), I still have some questions. > > > > First of all, what exactly is multi-seat? Does it just mean allowing > > multiple sessions to be running at once, like for multiple users to be > > logged into the same desktop, even though only one will be in use at a > > time? > > No, it means you can have multiple physical seats on the same > computer. i.e. one computer with two displays, two keyboards, two > mice, and that two people can work on it, independently of each other. Ok, that makes sense. That's where I got confused; after reading the definition of a "seat" in sd-login(3), I didn't get why a daemon would be required if each program is using either all or none of the hardware at one time. Now I see that logind assigns some (or all) hardware to a specific "seat" which a program can then run on, utilizing all the hardware in the seat, even though that isn't necessarily all the hardware on the system. > > Second, why is logind needed for this? Is it not possible to do without > > logind? I've run Xorg perfectly fine on systems without logind/systemd, > > so is logind only needed for multiple sessions at once? Is it just to > > handle the graphical device(s)? > > > > Third, is multi-seat possible at all without logind? > > > > Most of these questions arose because my main OS, Artix Linux, requires > > logind (in the form of elogind) for Xorg, but I know that Xorg runs just > > fine on Alpine Linux, which does not use logind at all. > > I have no idea of those distro. I could not possible answer what they > support and what not. > > Like any software problem, you can always hack up your alternative > solution. Software is generally reimplementable. If they reimplemented > it, good for them. They can also fork our stuff, or just use our > stuff, it's Free Software after all. > > Either way, please contact the maintainers of your distro and > "elogind" for help in general, this is the wrong forum for such > questions. I wasn't necessarily asking for help with those distros or elogind. I was just using those as an example of systems running both with and without systemd's logind. Sorry for the confusion. -- Kian Kasad PGP 0x1715EEAA14DAEC14 signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What exactly is multi-seat? -- questions about logind
On 21/01/26 02:06PM, Pekka Paalanen wrote: > On Tue, 26 Jan 2021 01:43:43 -0800 > Kian Kasad wrote: > > > Hi all, > > > > After reading the documentation on logind and multi-seat (specifically > > sd-login(3) and "Multi-Seat on Linux"), I still have some questions. > > > > First of all, what exactly is multi-seat? Does it just mean allowing > > multiple sessions to be running at once, like for multiple users to be > > logged into the same desktop, even though only one will be in use at a > > time? > > > > Second, why is logind needed for this? Is it not possible to do without > > logind? I've run Xorg perfectly fine on systems without logind/systemd, > > so is logind only needed for multiple sessions at once? Is it just to > > handle the graphical device(s)? > > > > Third, is multi-seat possible at all without logind? > > > > Most of these questions arose because my main OS, Artix Linux, requires > > logind (in the form of elogind) for Xorg, but I know that Xorg runs just > > fine on Alpine Linux, which does not use logind at all. > > Hi, > > I've heard good words of https://sr.ht/~kennylevinsen/seatd/ although I > haven't tried to use it myself. One more way to handle multiseat - to > bind them all. I'll write this one down. I'm not looking for alternatives currently, I was just confused about the purpose. > IOW, there are many ways to achieve coordination between multiple > sessions and one or multiple physical seats, like the Linux virtual > terminal system that requires root permissions, ioctl and signal magic > to let things cooperate (and if things do not explicitly cooperate > correctly, it fails horribly) and does not support multiseat. But if > you want your program to not need root permissions, have a graceful > failure if it crashes, not accidentally hijack the seat by mistake, or > just support multiseat, you kind of need to have a system daemon > orchestrating things. > > Logind is one of those possible system daemons. It tells your program > when it is active. It grants access to graphics and input devices > without your program needing root permissions. It also takes graphics > and input devices away from your program when deactivated, so you can't > e.g. spy on other programs' input. It takes care of the arcane magic of > setting up the VT and tty and restoring them. And more. > > "Your program" here is Xorg, for instance. Or one of the Wayland > compositors. Thank you! This is exactly the explanation I was looking for. I didn't get why a daemon was needed if programs (like Xorg) can handle the devices on their own, but now I see it's to allow multiple Xorg/Wayland sessions to run, all without needing SUID. -- Kian Kasad PGP 0x1715EEAA14DAEC14 signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Questions about systemd's "root storage daemon" concept
On Tue, 2021-01-26 at 11:30 +0100, Lennart Poettering wrote: > > > Imagine two parallel instances of systemd-udevd (IMO there are > > reasons > > to handle it like a "root storage daemon" in some distant future). > > Hmm, wa? naahh.. udev is about dicovery it should not be required to > maintain access to something you found. True. But if udev ran without interruption, we could get rid of coldplug after switching root. That could possibly save us a lot of trouble. Anyway, it's just a thought I find tempting. Regrads Martin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Questions about systemd's "root storage daemon" concept
On Di, 26.01.21 13:30, Martin Wilck (mwi...@suse.com) wrote: > On Tue, 2021-01-26 at 11:30 +0100, Lennart Poettering wrote: > > > > > Imagine two parallel instances of systemd-udevd (IMO there are > > > reasons > > > to handle it like a "root storage daemon" in some distant future). > > > > Hmm, wa? naahh.. udev is about dicovery it should not be required to > > maintain access to something you found. > > True. But if udev ran without interruption, we could get rid of > coldplug after switching root. That could possibly save us a lot of > trouble. And introduce new trouble. Usually the rules on the host are more comprehensive than those in the initrd. You have to coldplug for the bigger ruleset. If you want to avoid that you basically would have to pack up a ton more stuff into the initrd. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What exactly is multi-seat? -- questions about logind
On Tue, 26 Jan 2021 01:43:43 -0800 Kian Kasad wrote: > Hi all, > > After reading the documentation on logind and multi-seat (specifically > sd-login(3) and "Multi-Seat on Linux"), I still have some questions. > > First of all, what exactly is multi-seat? Does it just mean allowing > multiple sessions to be running at once, like for multiple users to be > logged into the same desktop, even though only one will be in use at a > time? > > Second, why is logind needed for this? Is it not possible to do without > logind? I've run Xorg perfectly fine on systems without logind/systemd, > so is logind only needed for multiple sessions at once? Is it just to > handle the graphical device(s)? > > Third, is multi-seat possible at all without logind? > > Most of these questions arose because my main OS, Artix Linux, requires > logind (in the form of elogind) for Xorg, but I know that Xorg runs just > fine on Alpine Linux, which does not use logind at all. Hi, I've heard good words of https://sr.ht/~kennylevinsen/seatd/ although I haven't tried to use it myself. One more way to handle multiseat - to bind them all. IOW, there are many ways to achieve coordination between multiple sessions and one or multiple physical seats, like the Linux virtual terminal system that requires root permissions, ioctl and signal magic to let things cooperate (and if things do not explicitly cooperate correctly, it fails horribly) and does not support multiseat. But if you want your program to not need root permissions, have a graceful failure if it crashes, not accidentally hijack the seat by mistake, or just support multiseat, you kind of need to have a system daemon orchestrating things. Logind is one of those possible system daemons. It tells your program when it is active. It grants access to graphics and input devices without your program needing root permissions. It also takes graphics and input devices away from your program when deactivated, so you can't e.g. spy on other programs' input. It takes care of the arcane magic of setting up the VT and tty and restoring them. And more. "Your program" here is Xorg, for instance. Or one of the Wayland compositors. Thanks, pq pgpcp0meN_LBT.pgp Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What exactly is multi-seat? -- questions about logind
On Tue, 26 Jan 2021 at 01:43:43 -0800, Kian Kasad wrote: > First of all, what exactly is multi-seat? Does it just mean allowing > multiple sessions to be running at once, like for multiple users to be > logged into the same desktop, even though only one will be in use at a > time? No, that's "fast user switching" (usually implemented in terms of virtual consoles). Multi-seat is when you have one PC with two screens and two keyboards, Alice sits in front of screen A and types into keyboard A, Bob simultaneously sits in front of screen B and types into keyboard B. Both people interact with their own desktop environment, neither person interacts with the other desktop environment, and there is a security boundary protecting each user from the other. Usually they each get their own set of USB ports, and Alice can plug in USB devices (in particular storage devices) without giving Bob access to them. > Second, why is logind needed for this? Is it not possible to do without > logind? You need either logind or something roughly equivalent to logind, to manage which screen, keyboard, mouse etc. belong to Alice and which set belong to Bob, and keep them separate. It doesn't *necessarily* have to be logind, but there needs to be a component with a vaguely similar role. The obsolete ConsoleKit (which was superseded by systemd-logind) was an older implementation of multi-seat. elogind probably implements multi-seat too, but this is the systemd mailing list, not the elogind mailing list. > Most of these questions arose because my main OS, Artix Linux, requires > logind (in the form of elogind) for Xorg, but I know that Xorg runs just > fine on Alpine Linux, which does not use logind at all. There are a lot of subtleties beyond "runs just fine". If Artix Linux has chosen to offer features that require a logind implementation, then they'll need a logind implementation. If Alpine Linux has chosen to treat those features as outside their scope, then they won't need logind. (Also, this is the systemd mailing list, not the elogind or Artix mailing list; if you are unsure about elogind's capabilities or why Artix requires it, I would suggest asking elogind or Artix people.) smcv ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] nspawn+networkd sometimes fail to configure IPv6 properly
While debugging a different problem (which I'll report in an issue in the GitHub repo), I found something which appears to be the underlying cause. I rebooted a machine which has five nspawn containers, all configured identically for networking (except for addresses, of course). Immediately after the boot, 'machinectl list' shows all five containers running, and all five are accessible over IPv4. However, only two are accessible over IPv6, and: --- root@net20:~# ip neigh show proxy 2607:5300:203:5215::1 dev ve-mail20 proxy 2607:5300:203:5215::1 dev ve-diw20 proxy --- Only two are listed with proxy addresses for the host on their veth devices; these are the two that are accessible. --- root@net20:~# machinectl stop ns3 root@net20:~# machinectl start ns3 root@net20:~# ip neigh show proxy 2607:5300:203:5215::1 dev ve-ns3 proxy 2607:5300:203:5215::1 dev ve-mail20 proxy 2607:5300:203:5215::1 dev ve-diw20 proxy --- After a stop/start of the 'ns3' container, it now has the necessary proxy address on its veth device, and it is accessible over IPv6. --- root@net20:~# machinectl stop matrix20 root@net20:~# machinectl start matrix20 root@net20:~# ip neigh show proxy 2607:5300:203:5215::1 dev ve-matrix20 proxy 2607:5300:203:5215::1 dev ve-ns3 proxy 2607:5300:203:5215::1 dev ve-mail20 proxy 2607:5300:203:5215::1 dev ve-diw20 proxy root@net20:~# machinectl stop ldl20 root@net20:~# machinectl start ldl20 root@net20:~# ip neigh show proxy 2607:5300:203:5215::1 dev ve-ldl20 proxy 2607:5300:203:5215::1 dev ve-matrix20 proxy 2607:5300:203:5215::1 dev ve-ns3 proxy 2607:5300:203:5215::1 dev ve-mail20 proxy 2607:5300:203:5215::1 dev ve-diw20 proxy --- Same results for stop/start of the remaining two containers; they get the necessary proxy address, and become reachable. I've got DEBUG logging enabled for systemd-networkd but there is no evidence of any problem related to proxy address addition (https://gist.github.com/kpfleming/4b6c721edaf9d2ff4a24dadbb002fb0c). I think the next step is going to be building systemd from source to verify that the Debian 247.2 packages aren't at fault, and then adding more debugging output in the necessary places. On Sun, Jan 24, 2021 at 10:14 AM Kevin P. Fleming wrote: > > I've got three systems which host nspawn-based containers, using > networkd for network configuration on both the host and inside the > containers. All of the systems are running Debian systemd packages > (some version 241 (buster) and some 247.2 (bullseye)). The behavior > has been seen with kernels 5.4, 5.9, and 5.10 (both Debian kernel > packages and a hand-built vanilla kernel package). There are no > firewalls in use. > > An example configuration: > > host - /etc/systemd/nspawn/mqtt20.nspawn > > [Files] > PrivateUsersChown=yes > [Network] > VirtualEthernetExtra=mqtt20:srv > > host - /etc/systemd/network/mqtt20.network > --- > [Match] > Name=mqtt20 > > [Network] > Address=192.168.254.108/32 > Address=fd80:ae6b:5f43:254::108/128 > > [Route] > Destination=192.168.64.108 > Scope=link > > [Route] > Destination=2001:470:8afe:64::108 > > [Route] > Destination=fd80:ae6b:5f43:64::108 > > container - /etc/systemd/network/primary.network > --- > [Match] > Name=srv > > [Network] > Address=192.168.64.108/32 > Address=2001:470:8afe:64::108/128 > Address=fd80:ae6b:5f43:64::108/128 > DNS=fd80:ae6b:5f43:1::8 > > [Route] > Destination=192.168.254.108/32 > Scope=link > > [Route] > Gateway=192.168.254.108 > Destination=0.0.0.0/0 > > [Route] > Destination=fd80:ae6b:5f43:254::108/128 > > [Route] > Gateway=fd80:ae6b:5f43:254::108 > Destination=::/0 > > --- > > Layer 3 networking is used, on virtual Ethernet devices. > > Sometimes, after a system startup, some of the containers are not > reachable over IPv6. When this happens, their IPv4 connectivity is > fine. Running 'machinectl stop ' followed by 'machinectl start ' > always cures the problem. > > When a container is in this state, 'ip link ls' and 'ip addr ls' on > the host and in the container don't display anything out of the > ordinary (the details match those of another container on the same > host which works properly). > > I've run tcpdump on the veth device for a broken container and then > sent ICMPv6 pings from another system on the network; what I see is > that the host sends IPv6 Neighbor Solicitation requests on the veth > device to discover the container's layer 2 address, but no replies are > sent. Running tcpdump inside the container shows the same thing; NS is > received, but no reply is sent. > > It's as if the IPv6 stack in the container's network namespace is > just... not listening at all. > > Can anyone suggest ways to troubleshoot this beyond the simple things > I've listed above? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What exactly is multi-seat? -- questions about logind
On Di, 26.01.21 01:43, Kian Kasad (k...@kasad.com) wrote: > Hi all, > > After reading the documentation on logind and multi-seat (specifically > sd-login(3) and "Multi-Seat on Linux"), I still have some questions. > > First of all, what exactly is multi-seat? Does it just mean allowing > multiple sessions to be running at once, like for multiple users to be > logged into the same desktop, even though only one will be in use at a > time? No, it means you can have multiple physical seats on the same computer. i.e. one computer with two displays, two keyboards, two mice, and that two people can work on it, independently of each other. > Second, why is logind needed for this? Is it not possible to do without > logind? I've run Xorg perfectly fine on systems without logind/systemd, > so is logind only needed for multiple sessions at once? Is it just to > handle the graphical device(s)? > > Third, is multi-seat possible at all without logind? > > Most of these questions arose because my main OS, Artix Linux, requires > logind (in the form of elogind) for Xorg, but I know that Xorg runs just > fine on Alpine Linux, which does not use logind at all. I have no idea of those distro. I could not possible answer what they support and what not. Like any software problem, you can always hack up your alternative solution. Software is generally reimplementable. If they reimplemented it, good for them. They can also fork our stuff, or just use our stuff, it's Free Software after all. Either way, please contact the maintainers of your distro and "elogind" for help in general, this is the wrong forum for such questions. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What exactly is multi-seat? -- questions about logind
Am 26.01.21 um 10:43 schrieb Kian Kasad: Hi all, After reading the documentation on logind and multi-seat (specifically sd-login(3) and "Multi-Seat on Linux"), I still have some questions. First of all, what exactly is multi-seat? Google "systemd multiseat" links to https://www.freedesktop.org/wiki/Software/systemd/multiseat/ it's really about seats, the stuff where you place your arse in front of your IO devices :-) Does it just mean allowing multiple sessions to be running at once, like for multiple users to be logged into the same desktop, even though only one will be in use at a time? Second, why is logind needed for this? Is it not possible to do without logind? I've run Xorg perfectly fine on systems without logind/systemd, so is logind only needed for multiple sessions at once? Is it just to handle the graphical device(s)? Third, is multi-seat possible at all without logind? Most of these questions arose because my main OS, Artix Linux, requires logind (in the form of elogind) for Xorg, but I know that Xorg runs just fine on Alpine Linux, which does not use logind at all you can start X11 with "startx" line in the 1990s but who is doing it that way these days? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Questions about systemd's "root storage daemon" concept
On Di, 26.01.21 01:19, Martin Wilck (mwi...@suse.com) wrote: > On Mon, 2021-01-25 at 18:33 +0100, Lennart Poettering wrote: > > > > Consider using IgnoreOnIsolate=. > > > > I fail to make this work. Installed this to the initrd (note the > ExecStop "command"): > > [Unit] > Description=NVMe Event Monitor for Automatical Subsystem Connection > Documentation=man:nvme-monitor(1) > DefaultDependencies=false > Conflicts=shutdown.target > Requires=systemd-udevd-kernel.socket > After=systemd-udevd-kernel.socket Why do you require this? My guess: the socket unit gets shutdown, and since you have Requires= on it you thus go away too. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Questions about systemd's "root storage daemon" concept
On Mo, 25.01.21 19:04, Martin Wilck (mwi...@suse.com) wrote: > Is there any way for the daemon to get notified if root is switched? /proc/self/mountinfo sends out notification events via inotify when mounts are established/removed. I am pretty sure pivot_root() also generates that. Your daemon could subscribe to that, and then recheck each time if /etc/initrd-release is still accessible. Once you see ENOENT on that you can assume the switch root took place, then close the inotify. > Would there be a potential security issue because the daemon keeps a > reference to the intird root FS? Modern initrds transition their own root to /run/initramfs anyway, so this shouldn't be a problem normally. > Imagine two parallel instances of systemd-udevd (IMO there are reasons > to handle it like a "root storage daemon" in some distant future). Hmm, wa? naahh.. udev is about dicovery it should not be required to maintain access to something you found. > > option two: if you cannot have multiple instances of your subsystem, > > then the only option is to make the initrd version manage > > everything. But of course, that sucks, but there's little one can do > > about that. > > Why would it be so bad? I would actually prefer a single instance for > most subsystems. But maybe I'm missing something. Well, because you can't update things on-the-fly then, you cannot reexec since everything is backed by initrd. You cannot restart things, and so on. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] What exactly is multi-seat? -- questions about logind
Hi all, After reading the documentation on logind and multi-seat (specifically sd-login(3) and "Multi-Seat on Linux"), I still have some questions. First of all, what exactly is multi-seat? Does it just mean allowing multiple sessions to be running at once, like for multiple users to be logged into the same desktop, even though only one will be in use at a time? Second, why is logind needed for this? Is it not possible to do without logind? I've run Xorg perfectly fine on systems without logind/systemd, so is logind only needed for multiple sessions at once? Is it just to handle the graphical device(s)? Third, is multi-seat possible at all without logind? Most of these questions arose because my main OS, Artix Linux, requires logind (in the form of elogind) for Xorg, but I know that Xorg runs just fine on Alpine Linux, which does not use logind at all. -- Kian Kasad PGP 0x1715EEAA14DAEC14 signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
