[systemd-devel] Antw: [EXT] Re: Still confused with socket activation
>>> Andrei Borzenkov schrieb am 03.02.2021 um 19:13 in Nachricht : > 02.02.2021 12:43, Ulrich Windl пишет: >> Hi! >> >> Having: >> --- >> # /usr/lib/systemd/system/virtlockd.service >> [Unit] >> Description=Virtual machine lock manager >> Requires=virtlockd.socket >> Requires=virtlockd-admin.socket > > That's always wrong with After for the same units unless you can prove > that both socket units are always ordered Before service unit due to > dependency chain, at least if intention is to ensure socket units are > active *before* service unit. In real life nobody notices it because > both sockets are started much earlier which papers over race condition. > > And if after 10 years of software existence everyone still gets it wrong > I strongly suspect something is not right with software, not with everyone. > >> Before=libvirtd.service >> ... >> --- >> >> How would I start both sockets successfully unter program control? > > I do not understand what you want to say here, sorry. What "program > control" means? What exactly are you trying to do? "program control" means "start"/"stop" vs. automatic control via "enable"/"disable". > >> If I start one socket, I cannot start the other without an error (as > libvirtd.service is running already, see my earlier message from last week). > > I do not see how starting socket unit is related to starting service > unit. Unless there was incoming traffic on socket. Also I do not > understand why you need to start socket units if you *already* started > service unit. Again, you do not really provide much coherent information > to do any suggestion. I had provided the full units yesterday. Basically I don't know what to do: I just want to start the service and its sockets at a specific point in time and also want to stop those at another time. > > And I do not really understand the reason to use two different socket > units that apparently are always started together and activate the same > service. Just create single socket unit that listens on both sockets. It seems the service has a config file that specified which sockets to use, and some magic has to activate/deactivate the corresponding socket units. (BTW: You can find a corresponding question at serverfault since yesterday) > >> If I mask the socket units, I cannot start the libvirtd.service. >> So would I disable the socket units and start libvirtd.service? > > You misunderstand what "disable" means in systemd (see remark above). > You cannot disable (in common sense) starting of socket units together > with virtlockd.service because starting of virtlockd.service will always > attempt to start both socket units (that is exactly what Requires/Wants > are about). That would be OK, but I don't want that the socket units get activated by some otherm echanism I still haven't identified. > > Actually if they are "enabled" (in systemd sense) then they are started > very early during boot, long before service unit. What exact problem you > have in this case? Pacemaker cluster provides a shared filesystem, so the units should not be started before that filesystem is mounted. Sounds simple, but systemd seems to make this hard to impossible. Regards, Ulrich > >> Unfortunately if someone (update when vendor-preset is enabled) re-enables > the socket units, it would break things, so I tried to mask them, but that > failed, too. >> error: Could not issue start for prm_virtlockd: Unit virtlockd.socket is > masked. >> >> Regards, >> Ulrich >> >> >> >> >> ___ >> systemd-devel mailing list >> systemd-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/systemd-devel >> > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev and btrfs multiple devices
On Wed, Feb 3, 2021 at 10:32 PM Chris Murphy wrote: > > On Thu, Jan 28, 2021 at 7:18 AM Lennart Poettering > wrote: > > > > On Mi, 27.01.21 17:19, Chris Murphy (li...@colorremedies.com) wrote: > > > > > Is it possible for a udev rule to have a timeout? For example: > > > /usr/lib/udev/rules.d/64-btrfs.rules > > > > > > This udev rule will wait indefinitely for a missing device to > > > appear. > > > > Hmm, no, that's a mis understaning. "rules" can't "wait". The > > activation of the btrfs file system won't happen, but that should then > > be caught by systemd mount timeouts and put you into recovery mode. > > It doesn't. It waits indefinitely. > > [* ] A start job is running for > /dev/disk/by-uuid/cf9c9518-45d4-43d6-8a0a-294994c383fa (12min 36s / no > limit) https://github.com/systemd/systemd/issues/18466 -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] consider dropping defrag of journals on btrfs
On Wed, Feb 3, 2021 at 9:46 AM Lennart Poettering wrote: > > Performance is terrible if cow is used on journal files while we write > them. I've done it for a year on NVMe. The latency is so low, it doesn't matter. > It would be great if we could turn datacow back on once the files are > archived, and then take benefit of compression/checksumming and > stuff. not sure if there's any sane API for that in btrfs besides > rewriting the whole file, though. Anyone knows? A compressed file results in a completely different encoding and extent size, so it's a complete rewrite of the whole file, regardless of the cow/nocow status. Without compression it'd be a rewrite because in effect it's a different extent type that comes with checksums. i.e. a reflink copy of a nodatacow file can only be a nodatacow file; a reflink copy of a datacow file can only be a datacow file. The conversion between them is basically 'cp --reflink=never' and you get a complete rewrite. But you get a complete rewrite of extents by submitting for defragmentation too, depending on the target extent size. It is possible to do what you want by no longer setting nodatacow on the enclosing dir. Create a 0 length journal file, set nodatacow on that file, then fallocate it. That gets you a nodatacow active journal. And then you can just duplicate it in place with a new name, and the result will be datacow and automatically compressed if compression is enabled. But the write hit has already happened by writing journal data into this journal file during its lifetime. Just rename it on rotate. That's the least IO impact possible at this point. Defragmenting it means even more writes, and not much of a gain if any, unless it's datacow which isn't the journald default. -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] consider dropping defrag of journals on btrfs
On Wed, Feb 3, 2021 at 9:41 AM Lennart Poettering wrote: > > On Di, 05.01.21 10:04, Chris Murphy (li...@colorremedies.com) 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. > > Quite frankly, given how iops-expensive btrfs is, one probably > shouldn't choose btrfs for such small devices anyway. It's really not > where btrfs shines, last time I looked. Btrfs aggressively delays metadata and data allocation, so I don't agree that it's expensive. There is a wandering trees problem that can result in write amplification, that's a different problem. But via native compression overall writes are proven to significantly reduce overall writes. But in any case, reading a journal file and rewriting it out, which is what defragment does, doesn't really have any benefit given the file doesn't fragment much anyway due to (a) nodatacow and (b) fallocate, which is what systemd-journald does on Btrfs. It'd make more sense to defragment only if the file is datacow. At least then it also gets compressed, which isn't the case when it's nodatacow. > > > 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? > > Did you actually check the iops this generates? I don't understand the relevance. > > Not sure it's worth doing these kind of optimizations without any hard > data how expensive this really is. It would be premature. Submitting the journal for defragment in effect duplicates the journal. Read all extents, and rewrite those blocks to a new location. It's doubling the writes for that journal file. It's not like the defragment is free. > That said, if there's actual reason to optimize the iops here then we > could make this smart: there's actually an API for querying > fragmentation: we could defrag only if we notice the fragmentation is > really too high. FIEMAP isn't going to work in the case the files are being fragmented. The Btrfs extent size becomes 128KiB in that case, and it looks like massive fragmentation. So that needs to be made smarter first. I don't have a problem submitting the journal for a one time defragment upon rotation if it's datacow, if empty journal-nocow.conf exists. But by default, the combination of fallocate and nodatacow already avoids all meaningful fragmentation, so long as the journals aren't being snapshot. If they are, well, that too is a different problem. If the user does that and we're still defragmenting the files, it'll explode their space consumption because defragment is not snapshot aware, it results in all shared extents becoming unshared. > But quite frankly, this sounds polishing things after the horse > already left the stable: if you want to optimize iops, then don't use > btrfs. If you bought into btrfs, then apparently you are OK with the > extra iops it generates, hence also the defrag costs. Somehow I think you're missing what I've asking for, which is to stop the unnecessary defragment step because it's not an optimization. It doesn't meaningfully reduce fragmentation at all, it just adds write amplification. -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev and btrfs multiple devices
On Thu, Jan 28, 2021 at 7:18 AM Lennart Poettering wrote: > > On Mi, 27.01.21 17:19, Chris Murphy (li...@colorremedies.com) wrote: > > > Is it possible for a udev rule to have a timeout? For example: > > /usr/lib/udev/rules.d/64-btrfs.rules > > > > This udev rule will wait indefinitely for a missing device to > > appear. > > Hmm, no, that's a mis understaning. "rules" can't "wait". The > activation of the btrfs file system won't happen, but that should then > be caught by systemd mount timeouts and put you into recovery mode. It doesn't. It waits indefinitely. [* ] A start job is running for /dev/disk/by-uuid/cf9c9518-45d4-43d6-8a0a-294994c383fa (12min 36s / no limit) -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Resolving of a specifier in Environment= and ExecStart=
Hello,
I've been trying to figure out how the same specifier, particularly %H, is
resolved in Environment= and ExecStart=. For that I use a VM with Centos 7 that
has systemd v219 (from systemd-219-78.el7_9.2.x86_64 rpm), and a
consul-template binary, that starts as systemd service.
The system unit of the latter is quite simple:
...
[Service]
...
Environment=HOSTNAME=%H
ExecStart=/usr/bin/env HOSTNAME=%H /usr/bin/consul-template $CMD_OPTS
...
After the VM has booted that process has the following:
$ hostname
vm-0005
$ sudo systemctl show consul-template | grep -E 'Environment|ExecStart'
ExecStart={ path=/usr/bin/env ; argv[]=/usr/bin/env HOSTNAME=%H
/usr/bin/consul-template $CMD_OPTS ; ignore_errors=no ; start_time=[Wed
2021-02-03 21:43:37 UTC] ; stop_time=[n/a] ; pid=1198 ; code=(null) ;
status=0/0 }
Environment=HOSTNAME=vm-0004
EnvironmentFile=/etc/sysconfig/consul-template (ignore_errors=no)
$ sudo grep -aoE 'HOSTNAME=[-a-z0-9]+' /proc/$(pidof consul-template)/environ
HOSTNAME=vm-0005
HOSTNAME=vm-0004 was set on a previous VM, that was used to create an image for
vm-0005.
>From all of that I have guess that expansion of the same specifier happens at
>different point in time for Environment= and for ExecStart=. Unfortunately, I
>could not find any references about that in the documentation. If I edit that
>system unit or reload systemd, Environment= will have HOSTNAME=vm-0005 value.
Could you please explain how the same specifier is resolved in different
directives?
Thank you.
--
Kind regards,
R
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Still confused with socket activation
On Wed, 2021-02-03 at 20:47 +0300, Andrei Borzenkov wrote: > 03.02.2021 00:25, Benjamin Berg пишет: > > On Tue, 2021-02-02 at 22:50 +0300, Andrei Borzenkov wrote: > > > 02.02.2021 17:59, Lennart Poettering пишет: > > > > > > > > Note that Requires= in almost all cases should be combined with > > > > an > > > > order dep of After= onto the same unit. > > > > > > Years ago I asked for example when Requires makes sense without > > > After. > > > Care to show it? I assume you must have use case if you say "in > > > almost all". > > > > In the GNOME systemd units there are a few places where a Requires= > > is > > combined with Before=. > > > > This is functionally completely equivalent to simply using > Wants+Before. > At least as long as you rely on *documented* functions. Requires= actually has the difference that the unit must become part of the transaction (if it is not active already). So you get a hard failure and appropriate logging if the unit cannot be added to the transaction for some reason. > Care to show more complete example and explain why Wants does not > work in this case? Wants= would work fine. I think it boils down to whether you find the extra assertions useful. The Requires= documentation actually suggests using Wants= exactly to avoid this. Benjamin signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Still confused with socket activation
03.02.2021 21:13, Andrei Borzenkov пишет: > 02.02.2021 12:43, Ulrich Windl пишет: >> Hi! >> >> Having: >> --- >> # /usr/lib/systemd/system/virtlockd.service >> [Unit] >> Description=Virtual machine lock manager >> Requires=virtlockd.socket >> Requires=virtlockd-admin.socket > > That's always wrong with After for the same units s/with/without/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Still confused with socket activation
02.02.2021 12:43, Ulrich Windl пишет: > Hi! > > Having: > --- > # /usr/lib/systemd/system/virtlockd.service > [Unit] > Description=Virtual machine lock manager > Requires=virtlockd.socket > Requires=virtlockd-admin.socket That's always wrong with After for the same units unless you can prove that both socket units are always ordered Before service unit due to dependency chain, at least if intention is to ensure socket units are active *before* service unit. In real life nobody notices it because both sockets are started much earlier which papers over race condition. And if after 10 years of software existence everyone still gets it wrong I strongly suspect something is not right with software, not with everyone. > Before=libvirtd.service > ... > --- > > How would I start both sockets successfully unter program control? I do not understand what you want to say here, sorry. What "program control" means? What exactly are you trying to do? > If I start one socket, I cannot start the other without an error (as > libvirtd.service is running already, see my earlier message from last week). I do not see how starting socket unit is related to starting service unit. Unless there was incoming traffic on socket. Also I do not understand why you need to start socket units if you *already* started service unit. Again, you do not really provide much coherent information to do any suggestion. And I do not really understand the reason to use two different socket units that apparently are always started together and activate the same service. Just create single socket unit that listens on both sockets. > If I mask the socket units, I cannot start the libvirtd.service. > So would I disable the socket units and start libvirtd.service? You misunderstand what "disable" means in systemd (see remark above). You cannot disable (in common sense) starting of socket units together with virtlockd.service because starting of virtlockd.service will always attempt to start both socket units (that is exactly what Requires/Wants are about). Actually if they are "enabled" (in systemd sense) then they are started very early during boot, long before service unit. What exact problem you have in this case? > Unfortunately if someone (update when vendor-preset is enabled) re-enables > the socket units, it would break things, so I tried to mask them, but that > failed, too. > error: Could not issue start for prm_virtlockd: Unit virtlockd.socket is > masked. > > Regards, > Ulrich > > > > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Still confused with socket activation
03.02.2021 00:25, Benjamin Berg пишет: > On Tue, 2021-02-02 at 22:50 +0300, Andrei Borzenkov wrote: >> 02.02.2021 17:59, Lennart Poettering пишет: >>> >>> Note that Requires= in almost all cases should be combined with an >>> order dep of After= onto the same unit. >> >> Years ago I asked for example when Requires makes sense without >> After. >> Care to show it? I assume you must have use case if you say "in >> almost all". > > In the GNOME systemd units there are a few places where a Requires= is > combined with Before=. > This is functionally completely equivalent to simply using Wants+Before. At least as long as you rely on *documented* functions. Care to show more complete example and explain why Wants does not work in this case? signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] consider dropping defrag of journals on btrfs
On Di, 26.01.21 21:00, Chris Murphy (li...@colorremedies.com) wrote: > 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). Performance is terrible if cow is used on journal files while we write them. It would be great if we could turn datacow back on once the files are archived, and then take benefit of compression/checksumming and stuff. not sure if there's any sane API for that in btrfs besides rewriting the whole file, though. Anyone knows? Just dropping FS_NOCOW_FL on the existing file doesn#t work iirc, it can only be changed while a file is empty last time i looked iirc. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] consider dropping defrag of journals on btrfs
On Di, 05.01.21 10:04, Chris Murphy (li...@colorremedies.com) 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. Quite frankly, given how iops-expensive btrfs is, one probably shouldn't choose btrfs for such small devices anyway. It's really not where btrfs shines, last time I looked. > 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? Did you actually check the iops this generates? Not sure it's worth doing these kind of optimizations without any hard data how expensive this really is. It would be premature. That said, if there's actual reason to optimize the iops here then we could make this smart: there's actually an API for querying fragmentation: we could defrag only if we notice the fragmentation is really too high. But quite frankly, this sounds polishing things after the horse already left the stable: if you want to optimize iops, then don't use btrfs. If you bought into btrfs, then apparently you are OK with the extra iops it generates, hence also the defrag costs. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Limitation on maximum number of systemd timers that can be active
On Mi, 03.02.21 12:16, P.R.Dinesh (pr.din...@gmail.com) wrote: > Do we have any limitation on the maximum number of systemd timers / units > that can be active in the system? We currently enforce a limit of 128K units. This is controlled by the MANAGER_MAX_NAMES define, which is hard compiled in. > Will it consume high cpu/memory if we configure 1000s of systemd timers? It will consume a bit of memory, but I'd guess it should scale OK. All scalability issues regarding number of units we saw many years ago, by now all slow paths have been fixed I am aware of. I mean, we can certainly still optimize stuff (i.e. "systemctl daemon-reload" is expensive), but things to my knowledge having a few K of units should be totally Ok. (But then again I don't run things like that myself, my knowledge is purely based on feedback, or the recent lack thereof) Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Still confused with socket activation
Am 03.02.21 um 10:43 schrieb Benjamin Berg: On Wed, 2021-02-03 at 08:00 +0100, Reindl Harald wrote: Am 02.02.21 um 22:25 schrieb Benjamin Berg: On Tue, 2021-02-02 at 22:50 +0300, Andrei Borzenkov wrote: 02.02.2021 17:59, Lennart Poettering пишет: Note that Requires= in almost all cases should be combined with an order dep of After= onto the same unit. Years ago I asked for example when Requires makes sense without After. Care to show it? I assume you must have use case if you say "in almost all". In the GNOME systemd units there are a few places where a Requires= is combined with Before= sounds like complete nonsense you can not require something at your own to be there but on the other hand start before it - at least by common sense The units are indeed non-trivial. I have put in a lot of effort to find a solution that both works and is robust in various failure modes. It may well be that there is a better approach with similar properties. But, session login and logout(!) is not quite as trivial as one could hope for unfortunately (backward compatibility and workarounds add some complexities). So, I would love to be educated on how to simplify all this while still catching the various corner cases. But in order to convince me, you'll need to make a more concrete suggestion and explain its properties seriously - explain what you expect to happen in case of Requires=a.service Before=a.service except some warning that it's nonsense you need a.service but want to be started before a.service sounds like wash me but don't make me wet ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Antw: [EXT] Limitation on maximum number of systemd timers that can be active
>>> "P.R.Dinesh" schrieb am 03.02.2021 um 07:46 in >>> Nachricht : > Do we have any limitation on the maximum number of systemd timers / units > that can be active in the system? > Will it consume high cpu/memory if we configure 1000s of systemd timers? What about trying? Probably depends on your machine. > > -- > With Kind Regards, > P R Dinesh ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Still confused with socket activation
On Wed, 2021-02-03 at 08:00 +0100, Reindl Harald wrote: > > > Am 02.02.21 um 22:25 schrieb Benjamin Berg: > > On Tue, 2021-02-02 at 22:50 +0300, Andrei Borzenkov wrote: > > > 02.02.2021 17:59, Lennart Poettering пишет: > > > > > > > > Note that Requires= in almost all cases should be combined with > > > > an > > > > order dep of After= onto the same unit. > > > > > > Years ago I asked for example when Requires makes sense without > > > After. > > > Care to show it? I assume you must have use case if you say "in > > > almost all". > > > > In the GNOME systemd units there are a few places where a Requires= > > is > > combined with Before= > > sounds like complete nonsense > > you can not require something at your own to be there but on the other > hand start before it - at least by common sense The units are indeed non-trivial. I have put in a lot of effort to find a solution that both works and is robust in various failure modes. It may well be that there is a better approach with similar properties. But, session login and logout(!) is not quite as trivial as one could hope for unfortunately (backward compatibility and workarounds add some complexities). So, I would love to be educated on how to simplify all this while still catching the various corner cases. But in order to convince me, you'll need to make a more concrete suggestion and explain its properties. Benjamin signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Antw: [EXT] Re: Still confused with socket activation
>>> Lennart Poettering schrieb am 02.02.2021 um 15:59 in Nachricht <20210202145954.GB36677@gardel-login>: > On Di, 02.02.21 10:43, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de) wrote: > >> Hi! >> >> Having: >> ‑‑‑ >> # /usr/lib/systemd/system/virtlockd.service >> [Unit] >> Description=Virtual machine lock manager >> Requires=virtlockd.socket >> Requires=virtlockd‑admin.socket >> Before=libvirtd.service >> ... >> ‑‑‑ >> >> How would I start both sockets successfully unter program control? >> If I start one socket, I cannot start the other without an error (as > libvirtd.service is running already, see my earlier message from last week). >> If I mask the socket units, I cannot start the libvirtd.service. >> So would I disable the socket units and start libvirtd.service? >> Unfortunately if someone (update when vendor‑preset is enabled) re‑enables the > socket units, it would break things, so I tried to mask them, but that > failed, too. >> error: Could not issue start for prm_virtlockd: Unit virtlockd.socket is > masked. > > I don't grok what you are trying to say, the excerpt of the unit file > is too short. Please provide the relevant parts of the other unit > files too. So you get it: # systemctl cat virtlockd.service # /usr/lib/systemd/system/virtlockd.service [Unit] Description=Virtual machine lock manager Requires=virtlockd.socket Requires=virtlockd-admin.socket Before=libvirtd.service Documentation=man:virtlockd(8) Documentation=https://libvirt.org [Service] EnvironmentFile=-/etc/sysconfig/virtlockd ExecStart=/usr/sbin/virtlockd $VIRTLOCKD_ARGS ExecReload=/bin/kill -USR1 $MAINPID # Loosing the locks is a really bad thing that will # cause the machine to be fenced (rebooted), so make # sure we discourage OOM killer OOMScoreAdjust=-900 # Needs to allow for max guests * average disks per guest # libvirtd.service written to expect 4096 guests, so if we # allow for 10 disks per guest, we get: LimitNOFILE=40960 [Install] Also=virtlockd.socket # /run/systemd/system/virtlockd.service.d/50-pacemaker.conf [Unit] Description=Cluster Controlled virtlockd Before=pacemaker.service pacemaker_remote.service [Service] Restart=no # systemctl cat virtlockd.socket # /usr/lib/systemd/system/virtlockd.socket [Unit] Description=Virtual machine lock manager socket Before=libvirtd.service [Socket] ListenStream=/run/libvirt/virtlockd-sock SocketMode=0600 [Install] WantedBy=sockets.target # /usr/lib/systemd/system/virtlockd-admin.socket [Unit] Description=Virtual machine lock manager admin socket Before=libvirtd.service BindsTo=virtlockd.socket After=virtlockd.socket [Socket] ListenStream=/run/libvirt/virtlockd-admin-sock Service=virtlockd.service SocketMode=0600 [Install] WantedBy=sockets.target To make things worse: libvirtd also requires virtlockd: # systemctl cat libvirtd.service # /usr/lib/systemd/system/libvirtd.service [Unit] Description=Virtualization daemon Requires=virtlogd.socket Requires=virtlockd.socket # Use Wants instead of Requires so that users # can disable these three .socket units to revert # to a traditional non-activation deployment setup Wants=libvirtd.socket Wants=libvirtd-ro.socket Wants=libvirtd-admin.socket Wants=systemd-machined.service Before=libvirt-guests.service After=network.target After=dbus.service After=iscsid.service After=apparmor.service After=local-fs.target After=remote-fs.target After=systemd-logind.service After=systemd-machined.service After=xencommons.service Conflicts=xendomains.service Documentation=man:libvirtd(8) Documentation=https://libvirt.org [Service] Type=notify EnvironmentFile=-/etc/sysconfig/libvirtd ExecStart=/usr/sbin/libvirtd $LIBVIRTD_ARGS ExecReload=/bin/kill -HUP $MAINPID KillMode=process Restart=on-failure # At least 1 FD per guest, often 2 (eg qemu monitor + qemu agent). # eg if we want to support 4096 guests, we'll typically need 8192 FDs # If changing this, also consider virtlogd.service & virtlockd.service # limits which are also related to number of guests LimitNOFILE=8192 # The cgroups pids controller can limit the number of tasks started by # the daemon, which can limit the number of domains for some hypervisors. # A conservative default of 8 tasks per guest results in a TasksMax of # 32k to support 4096 guests. TasksMax=32768 [Install] WantedBy=multi-user.target Also=virtlockd.socket Also=virtlogd.socket Also=libvirtd.socket Also=libvirtd-ro.socket # systemctl cat libvirtd.socket # /usr/lib/systemd/system/libvirtd.socket [Unit] Description=Libvirt local socket Before=libvirtd.service [Socket] # The directory must match the /etc/libvirt/libvirtd.conf unix_sock_dir setting # when using systemd version < 227 ListenStream=/run/libvirt/libvirt-sock Service=libvirtd.service SocketMode=0666 [Install] WantedBy=sockets.target # systemctl cat libvirtd-admin.socket # /usr/lib/systemd/system/libvirtd-admin.socket [Unit] Description=Libvirt admin socket Before=libvirtd.service BindsTo=libvirtd.socket After=libvirtd.socket [Socket] #
