Re: [systemd-devel] Submitting a service activation to remote mounts success
On Tue, Feb 06, 2024 at 05:06:02PM +0100, Silvio Knizek wrote: > Am Dienstag, dem 06.02.2024 um 16:15 +0100 schrieb Thomas HUMMEL: > > Hello, > >=20 > > I'm using systemd-239-74 on RHEL 8.8 EUS. > >=20 > > I was wondering if one can express the following : > >=20 > > start some service *only and only if/when* all remote mounts (ex: nfs,= > =20 > > some parallel fs) has *succeeded*, taking into account it may take some= > =20 > > time for some mount (some fs clients just live curl | sh themselves at= > =20 > > start !) to finish (which seems to exlude usage of=20 > > AssertPathIsMountPoint for instance, as it would not wait, or would it ?) > >=20 > > I have no auto option in the fstab for those fs and they use the _netdev= > =20 > > option > >=20 > > Obvisouly I could statically list all the mounts units as an ordering=20 > > dependency but this is not what I was looking for as there are namy (and= > =20 > > I'm not even sure - see below - it it would be enough) > >=20 > > Exploring this question I stumbled upon the following points : > >=20 > > my understanding is that: > >=20 > > 1. remote-fs.target special target is pulled in by multi-user.target and= > =20 > > is added by systemd-fstab-generator as a Before=3D ordering dep to all= > =20 > > remote .mount units > >=20 > > -> I also see a remote-fs.target has a Requires=3D=20 > > activation dep : I probably missed it in the doc but I don't see this=20 > > listed in neither implicit nor default dep : where does it come from ? > >=20 > > 2. Before=3D/After=3D refer, in the case of service units, to when the un= > it=20 > > has "finished starting up", this being defined by "when it returns=20 > > failed or success", which is dependent of the Type=3D of the service > >=20 > > Is this understanding correct ? > >=20 > > But when the unit is of type mount : what's the semantic of Before/After= > =20 > > ? (I don't think I saw it in the doc neither) > >=20 > > What's the meaning/use of Type=3Dnone in a .mount unit ? > >=20 > > My experience is that the mount may fail and remote-fs.target will still= > =20 > > be reached, even if one replace Requires with BindsTo, correct ? > >=20 > > So success or failure of the mount process does not seem to be involved= > =20 > > in the ordering dep, or does it ? > >=20 > > Thanks for your help > > Hi Thomas, > > RequiresMountsFor=3D should be your friend. It just takes a space- > separated list of paths and does all the other stuff by itself. > > Another options would be to switch to x-systemd.automount in fstab for > the network shares, so they will be mounted on first access, not > necessary during early boot when there is no network. FYI, it looks like your mailer used quoted-printable encoding, but didn’t set the appropriate headers to indicate that this encoding is in use. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature
Re: [systemd-devel] Bump: Testing LogFilterPatterns= on user-level services
On Fri, Jan 26, 2024 at 09:11:24AM +0100, Lennart Poettering wrote: > On Do, 25.01.24 22:29, Farblos (akfkqu.9df...@vodafonemail.de) wrote: > > > Hi. > > > > I sent below mail some week ago, Barry's reply left me unsure as to > > whether this would be a bug or not. I still tend do assume that I'm > > "doing something wrong". > > This is currently not supported. The filters are communicated by the > service manager to journald via xattrs on the cgroups, and journald > will only consider those for cgroups owned by root, i.e. not on > cgroups delegated to unpriv users like this done for systemd --user > instances. > > Interepreting arbitrary regexes configured by unpriv code in priv code > comes at some risk,. becose afair constructing them can come at O(2^n) > time, i.e. a rogue regex could make use consume unbounded time on > processing journal messages. Which regex engine is used? glibc’s engine is not safe for use with untrusted input, but Rust’s is, so that might be an option in the future. It isn’t OOM-safe, though. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature
Re: [RFC] initoverlayfs - a scalable initial filesystem
On Tue, Dec 12, 2023 at 06:40:32PM +0100, Lennart Poettering wrote: > On Mo, 11.12.23 12:48, Eric Curtin (ecur...@redhat.com) wrote: > > > Although the nice thing about a storage-init like approach is there's > > basically zero copies up front. What storage-init is trying to be, is > > a tool to just call systemd storage things, without also inheriting > > all the systemd stack. > > Just to make this clear: using things like systemd-cryptsetup outside > of the systemd stack is not going to work once you leave trivial > setups. i.e. the TPM hookup involves multiple services these days, and > it's not going to get any simpler. i.e. systemd-tpm2-setup, > systemd-pcrextend, systemd-pcrlock and so on. I am sorry, but doing > reasonable disk encryption with TPM involved means you either buy into > the whole systemd offer (i.e. with the service manager) or you have to > rewrite your own systemd. > > But maybe I am misunderstanding what you are saying here. I think a key factor here is that the initial suggestion was for automotive use cases. One can have a vastly simpler system if one is willing to deliver hardware-specific images, rather than trying to have a single image that supports many different hardware models. Automotive and other embedded systemd understandably do not want to pay for complexity that they do not need, and which is present to support features (such as supporting arbitrary hardware) they will never use. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature
Re: IPv6 Compliance for networkd
On Mon, Dec 11, 2023 at 10:52:31PM +, Muggeridge, Matt wrote: > > > > -Original Message- > > From: Demi Marie Obenour > > Sent: Tuesday, December 12, 2023 7:14 AM > > To: Muggeridge, Matt ; systemd- > > de...@lists.freedesktop.org > > Subject: Re: IPv6 Compliance for networkd > > > > On Mon, Dec 11, 2023 at 07:14:27PM +, Muggeridge, Matt wrote: > > > Hello, networkd developer community, > > > > > > I am hoping to rally support for making networkd IPv6 compliant and I'm > > > will > > to help, but cannot do it alone. Is there any interest in making systemd- > > networkd IPv6 compliant? > > > > > > There are many organizations (especially US Government) that mandate > > IPv6 compliance (USGv6). Products that are dependent on networkd cannot > > be bid to these customers. > > > > > > How do I engage with the right people in the developer community? > > > > > > Thanks, > > > Matt. > > > PS: Mailing list topics go unanswered and github issues get lost in the > > > noise, > > so I'm hoping there's a more efficient way to collaborate. > > > > In what specific ways is networkd not compliant? > > -- > > Sincerely, > > Demi Marie Obenour (she/her/hers) > > Invisible Things Lab > > Hi Demi, > > > In what specific ways is networkd not compliant? > > Refer to previous mailing list topics [1] and github issues, especially any > issues opened by LiveFreeAndRoam [2]. > > Are you a networkd developer? Are you willing to collaborate on this? > > [1] > https://www.mail-archive.com/search?a=1=systemd-devel%40lists.freedesktop.org=ipv6+compliance=0=0===1d===relevance > [2] > https://github.com/systemd/systemd/issues?q=is%3Aissue+author%3Alivefreeandroam If you need these problems fixed so that you can use systemd-networkd in your commercial products, I recommend getting your company to pay developers to fix systemd-networkd. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature
Re: [RFC] initoverlayfs - a scalable initial filesystem
On Mon, Dec 11, 2023 at 08:58:58PM +, Luca Boccassi wrote: > On Mon, 11 Dec 2023 at 20:43, Demi Marie Obenour > wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > On Mon, Dec 11, 2023 at 08:15:27PM +, Luca Boccassi wrote: > > > On Mon, 11 Dec 2023 at 17:30, Demi Marie Obenour > > > wrote: > > > > > > > > On Mon, Dec 11, 2023 at 10:57:58AM +0100, Lennart Poettering wrote: > > > > > On Fr, 08.12.23 17:59, Eric Curtin (ecur...@redhat.com) wrote: > > > > > > > > > > > Here is the boot sequence with initoverlayfs integrated, the > > > > > > mini-initramfs contains just enough to get storage drivers loaded > > > > > > and > > > > > > storage devices initialized. storage-init is a process that is not > > > > > > designed to replace init, it does just enough to initialize storage > > > > > > (performs a targeted udev trigger on storage), switches to > > > > > > initoverlayfs as root and then executes init. > > > > > > > > > > > > ``` > > > > > > fw -> bootloader -> kernel -> mini-initramfs -> initoverlayfs -> > > > > > > rootfs > > > > > > > > > > > > fw -> bootloader -> kernel -> storage-init -> init > > > > > > -> > > > > > > ``` > > > > > > > > > > I am not sure I follow what these chains are supposed to mean? Why are > > > > > there two lines? > > > > > > > > > > So, I generally would agree that the current initrd scheme is not > > > > > ideal, and we have been discussing better approaches. But I am not > > > > > sure your approach really is useful on generic systems for two > > > > > reasons: > > > > > > > > > > 1. no security model? you need to authenticate your initrd in > > > > >2023. There's no execuse to not doing that anymore these days. Not > > > > >in automotive, and not anywhere else really. > > > > > > > > > > 2. no way to deal with complex storage? i.e. people use FDE, want to > > > > >unlock their root disks with TPM2 and similar things. People use > > > > >RAID, LVM, and all that mess. > > > > > > > > > > Actually the above are kinda the same problem in a way: you need > > > > > complex storage, but if you need that you kinda need udev, and > > > > > services, and then also systemd and all that other stuff, and that's > > > > > why the system works like the system works right now. > > > > > > > > > > Whenever you devise a system like yours by cutting corners, and > > > > > declaring that you don't want TPM, you don't want signed initrds, you > > > > > don't want to support weird storage, you just solve your problem in a > > > > > very specific way, ignoring the big picture. Which is OK, *if* you can > > > > > actually really work without all that and are willing to maintain the > > > > > solution for your specific problem only. > > > > > > > > > > As I understand you are trying to solve multiple problems at once > > > > > here, and I think one should start with figuring out clearly what > > > > > those are before trying to address them, maybe without compromising on > > > > > security. So my guess is you want to address the following: > > > > > > > > > > 1. You don't want the whole big initrd to be read off disk on every > > > > >boot, but only the parts of it that are actually needed. > > > > > > > > > > 2. You don't want the whole big initrd to be fully decompressed on > > > > > every > > > > >boot, but only the parts of it that are actually needed. > > > > > > > > > > 3. You want to share data between root fs and initrd > > > > > > > > > > 4. You want to save some boot time by not bringing up an init system > > > > >in the initrd once, then tearing it down again, and starting it > > > > >again from the root fs. > > > > > > > > > > For the items listed above I think you can find different solutions > > > > > which do not necessarily compromise security as much. > > &g
Re: IPv6 Compliance for networkd
On Mon, Dec 11, 2023 at 07:14:27PM +, Muggeridge, Matt wrote: > Hello, networkd developer community, > > I am hoping to rally support for making networkd IPv6 compliant and I'm will > to help, but cannot do it alone. Is there any interest in making > systemd-networkd IPv6 compliant? > > There are many organizations (especially US Government) that mandate IPv6 > compliance (USGv6). Products that are dependent on networkd cannot be bid to > these customers. > > How do I engage with the right people in the developer community? > > Thanks, > Matt. > PS: Mailing list topics go unanswered and github issues get lost in the > noise, so I'm hoping there's a more efficient way to collaborate. In what specific ways is networkd not compliant? -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature
Re: [RFC] initoverlayfs - a scalable initial filesystem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, Dec 11, 2023 at 08:15:27PM +, Luca Boccassi wrote: > On Mon, 11 Dec 2023 at 17:30, Demi Marie Obenour > wrote: > > > > On Mon, Dec 11, 2023 at 10:57:58AM +0100, Lennart Poettering wrote: > > > On Fr, 08.12.23 17:59, Eric Curtin (ecur...@redhat.com) wrote: > > > > > > > Here is the boot sequence with initoverlayfs integrated, the > > > > mini-initramfs contains just enough to get storage drivers loaded and > > > > storage devices initialized. storage-init is a process that is not > > > > designed to replace init, it does just enough to initialize storage > > > > (performs a targeted udev trigger on storage), switches to > > > > initoverlayfs as root and then executes init. > > > > > > > > ``` > > > > fw -> bootloader -> kernel -> mini-initramfs -> initoverlayfs -> rootfs > > > > > > > > fw -> bootloader -> kernel -> storage-init -> init -> > > > > ``` > > > > > > I am not sure I follow what these chains are supposed to mean? Why are > > > there two lines? > > > > > > So, I generally would agree that the current initrd scheme is not > > > ideal, and we have been discussing better approaches. But I am not > > > sure your approach really is useful on generic systems for two > > > reasons: > > > > > > 1. no security model? you need to authenticate your initrd in > > >2023. There's no execuse to not doing that anymore these days. Not > > >in automotive, and not anywhere else really. > > > > > > 2. no way to deal with complex storage? i.e. people use FDE, want to > > >unlock their root disks with TPM2 and similar things. People use > > >RAID, LVM, and all that mess. > > > > > > Actually the above are kinda the same problem in a way: you need > > > complex storage, but if you need that you kinda need udev, and > > > services, and then also systemd and all that other stuff, and that's > > > why the system works like the system works right now. > > > > > > Whenever you devise a system like yours by cutting corners, and > > > declaring that you don't want TPM, you don't want signed initrds, you > > > don't want to support weird storage, you just solve your problem in a > > > very specific way, ignoring the big picture. Which is OK, *if* you can > > > actually really work without all that and are willing to maintain the > > > solution for your specific problem only. > > > > > > As I understand you are trying to solve multiple problems at once > > > here, and I think one should start with figuring out clearly what > > > those are before trying to address them, maybe without compromising on > > > security. So my guess is you want to address the following: > > > > > > 1. You don't want the whole big initrd to be read off disk on every > > >boot, but only the parts of it that are actually needed. > > > > > > 2. You don't want the whole big initrd to be fully decompressed on every > > >boot, but only the parts of it that are actually needed. > > > > > > 3. You want to share data between root fs and initrd > > > > > > 4. You want to save some boot time by not bringing up an init system > > >in the initrd once, then tearing it down again, and starting it > > >again from the root fs. > > > > > > For the items listed above I think you can find different solutions > > > which do not necessarily compromise security as much. > > > > > > So, in the list above you could address the latter three like this: > > > > > > 2. Use an erofs rather than a packed cpio as initrd. Make the boot > > >loader load the erofs into contigous memory, then use memmap=X!Y on > > >the kernel cmdline to synthesize a block device from that, which > > >you then mount directly (without any initrd) via > > >root=/dev/pmem0. This means yout boot loader will still load the > > >whole image into memory, but only decompress the bits actually > > >neeed. (It also has some other nice benefits I like, such as an > > >immutable rootfs, which tmpfs-based initrds don't have.) > > > > > > 3. Simply never transition to the root fs, don't marke the initrds in > > >systemd's eyes as an initrd (specifically: don't add an > > >/etc/initrd-release file to it). Inste
Re: [RFC] initoverlayfs - a scalable initial filesystem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, Dec 11, 2023 at 05:03:13PM +, Eric Curtin wrote: > On Mon, 11 Dec 2023 at 16:36, Demi Marie Obenour > wrote: > > > > On Mon, Dec 11, 2023 at 10:57:58AM +0100, Lennart Poettering wrote: > > > On Fr, 08.12.23 17:59, Eric Curtin (ecur...@redhat.com) wrote: > > > > > > > Here is the boot sequence with initoverlayfs integrated, the > > > > mini-initramfs contains just enough to get storage drivers loaded and > > > > storage devices initialized. storage-init is a process that is not > > > > designed to replace init, it does just enough to initialize storage > > > > (performs a targeted udev trigger on storage), switches to > > > > initoverlayfs as root and then executes init. > > > > > > > > ``` > > > > fw -> bootloader -> kernel -> mini-initramfs -> initoverlayfs -> rootfs > > > > > > > > fw -> bootloader -> kernel -> storage-init -> init -> > > > > ``` > > > > > > I am not sure I follow what these chains are supposed to mean? Why are > > > there two lines? > > > > > > So, I generally would agree that the current initrd scheme is not > > > ideal, and we have been discussing better approaches. But I am not > > > sure your approach really is useful on generic systems for two > > > reasons: > > > > > > 1. no security model? you need to authenticate your initrd in > > >2023. There's no execuse to not doing that anymore these days. Not > > >in automotive, and not anywhere else really. > > > > > > 2. no way to deal with complex storage? i.e. people use FDE, want to > > >unlock their root disks with TPM2 and similar things. People use > > >RAID, LVM, and all that mess. > > > > > > Actually the above are kinda the same problem in a way: you need > > > complex storage, but if you need that you kinda need udev, and > > > services, and then also systemd and all that other stuff, and that's > > > why the system works like the system works right now. > > > > > > Whenever you devise a system like yours by cutting corners, and > > > declaring that you don't want TPM, you don't want signed initrds, you > > > don't want to support weird storage, you just solve your problem in a > > > very specific way, ignoring the big picture. Which is OK, *if* you can > > > actually really work without all that and are willing to maintain the > > > solution for your specific problem only. > > > > > > As I understand you are trying to solve multiple problems at once > > > here, and I think one should start with figuring out clearly what > > > those are before trying to address them, maybe without compromising on > > > security. So my guess is you want to address the following: > > > > > > 1. You don't want the whole big initrd to be read off disk on every > > >boot, but only the parts of it that are actually needed. > > > > > > 2. You don't want the whole big initrd to be fully decompressed on every > > >boot, but only the parts of it that are actually needed. > > > > > > 3. You want to share data between root fs and initrd > > > > > > 4. You want to save some boot time by not bringing up an init system > > >in the initrd once, then tearing it down again, and starting it > > >again from the root fs. > > > > > > For the items listed above I think you can find different solutions > > > which do not necessarily compromise security as much. > > > > > > So, in the list above you could address the latter three like this: > > > > > > 2. Use an erofs rather than a packed cpio as initrd. Make the boot > > >loader load the erofs into contigous memory, then use memmap=X!Y on > > >the kernel cmdline to synthesize a block device from that, which > > >you then mount directly (without any initrd) via > > >root=/dev/pmem0. This means yout boot loader will still load the > > >whole image into memory, but only decompress the bits actually > > >neeed. (It also has some other nice benefits I like, such as an > > >immutable rootfs, which tmpfs-based initrds don't have.) > > > > > > 3. Simply never transition to the root fs, don't marke the initrds in > > >systemd's eyes as an initrd (specifically: don't add an > > >/etc/initrd-release file to it). Inste
Re: [RFC] initoverlayfs - a scalable initial filesystem
generic solution to this > is hard. My current thinking for this could be something like this, > covering the UEFI world: support sticking a DDI for the main initrd in > the ESP. The ESP is per definition unencrypted and unauthenticated, > but otherwise relatively well defined, i.e. known to be vfat and > discoverable via UUID on a GPT disk. So: build a minimal > single-process initrd into the kernel (i.e. UKI) that has exactly the > storage to find a DDI on the ESP, and set it up. i.e. vfat+erofs fs > drivers, and dm-verity. Then have a PID 1 that does exactly enough to > jump into the rootfs stored in the ESP. That latter then has proper > file system drivers, storage drivers, crypto stack, and can unlock the > real root. This would still be a pretty specific solution to one set > of devices though, as it could not cover network boots (i.e. where > there is just no ESP to boot from), but I think this could be kept > relatively close, as the logic in that case could just fall back into > loading the DDI that normally would still in the ESP fully into > memory. I don't think this is "a pretty specific solution to one set of devices" _at all_. To the contrary, it is _exactly_ what I want to see desktop systems moving to in the future. It solves the problem of large firmware images. It solves the problem of device-specific configuration, because one can use a file on the EFI system partition that is read by userspace and either treated as untrusted or TPM-signed. It means that one have a complete set of recovery tools in the event of a problem, rather than being limited to whatever one can squeese into an initramfs. One can even include a full GUI stack (with accessibility support!), rather than just Plymouth. For Qubes OS, one can include enough of the Xen and Qubes toolstack to even launch virtual machines, allowing the use of USB devices and networking for recovery purposes. It even means that one can use a FIDO2 token to unlock the hard drive without a USB stack on the host. And because the initramfs _only_ needs to load the boot extension volume, it can be very, _very_ small, which works great with using Linux as a coreboot payload. The only problem I can see that this does not solve is network boot, but that is very much a niche use case when compared to the millions of Fedora or Debian desktop installs, or even the tens of thousands of Qubes OS installs. Furthermore, I would _much_ rather network boot be handled by userspace and kexec, rather than the closed source UEFI network stack. It does require some care when upgrading, as the dm-verity image and the UKI cannot both be updated atomically, but one can solve that by first writing the new dm-verity image to a separate location. The UKI will try both both the old and new locations for the dm-verity image and rename the new image over the old one on success. The wrong image will simply fail to mount as its root hash will be wrong. This even allows Apple-esque boot policies to be implemented on commodity hardware, provided that the system firmware is sufficiently hardened. It won't be as good as what Apple does, but it will be a huge win from what is possible today. > (If you are focussing on systems lacking UEFI, then replace the word > "ESP" in the above with a similar concept, i.e. a well discoverable, > unauthenticated relatively simple file system, such as vfat). > > Anyway, I can't tell you how to solve your specific problems, but if > there's one thing I'd suggest you to keep in mind then it's the > security angle, i.e. keep in mind from the beginning how > authentication of every component of your process shall work, how > unatteneded disk encryption shall operate and how measurement shall > work. Security must be built into things from the beginning, not be > added as an afterthought. As a Qubes OS developer and a security researcher, thank you. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature
[systemd-devel] systemd-pcrlock: what prevents unauthorized changes to the NV index?
What prevents unauthorized changes to the NV index used by systemd-pcrlock? Is the secret key itself stored in the NV index, with the policy deciding who can read the key? Or does the policy on the NV index require that the policy established by systemd-pcrlock is itself satisfied before the NV index can be changed? In the latter case, does this mean that the index can be "leaked" in certain error conditions? -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature
Re: [systemd-devel] [help] Benchmarking software shows degraded performance
On Wed, Nov 29, 2023 at 09:36:04PM -0800, Christian Hergert wrote: > On 11/29/23 8:09 PM, nayabbasha.sa...@microchip.com wrote: > > One of the benchmark case is, where it simply opens graphical window on > > LCD screen and then simply closes it. For this case, the egt-benchmark > > shows 9 iterations/sec for busybox init. And it's only 5 iterations/sec > > for systemd init. > > Have you run perf or some other whole-system profiler on the system to see > what time is spent in what process and how the systemd case differs from the > busybox case? Does perf even support these single core SoCs? -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature
Re: [systemd-devel] setting cpulimit/iolimit on mysql thread not entire process
On Tue, Nov 28, 2023 at 08:35:29AM +0200, Mantas Mikulėnas wrote: > On Tue, Nov 28, 2023 at 8:27 AM jai wrote: > > > I am able to set cpulimit, iolimit, etc for a process using its pid > > through cgroups v2. But for some threads of a single mysql process, how can > > I achieve that? > > > > You cannot; 1) the limits are per-cgroup and the entire service is a single > cgroup; 2) the threads are created by mysqld, not by systemd, and systemd > does not monitor and move service processes across cgroups once the service > is already running; 3) afaik, in cgroups v2 it isn't even allowed for > threads of a single process to straddle multiple cgroups anymore. > > I'm not a DBA but I've heard that one common way to handle this would be to > create a separate MySQL instance (probably on a separate machine, even) > that would replicate all the data, for the heavy users to query. (Or the > other way around, main instance for the heavy updates ⇒ replica for regular > queries.) Generally heavy analytical queries should be on a replica. The reason is that analytical queries are less likely to need the very latest data, whereas transactions probably do. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature
Re: [systemd-devel] Starting a service before any networking
On Tue, Sep 26, 2023 at 11:50:55AM +0100, Mark Rogers wrote: > I'm sure this is trivial but I've gone round in circles without success. > > I have a script which reads from an SQLite database and generates various > system configuration files - at the moment these are dhcpcd.conf and > wpa_supplicant.conf but this might grow in future. > > As such the only dependency the script has is that the filesystem is up and > running. But the script must complete before anything that the script > manages the configuration file for. > > My current unit looks like this: > [Unit] > Before=networking.service > After=local-fs.target > > [Service] > Type=oneshot > ExectStart=/path/to/script > > [Install] > RequiredBy=network.target > > Where am I going wrong and what is the right way to do this? > > I've also tried Before=network-pre.target and Wants=network-pre.target > without success - it was that not working that set me off trying to fix it. RequiredBy=network-pre.target should be sufficient, but unfortunately lots of stuff (like systemd-networkd) that should have Requires=network-pre.target doesn't. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature
Re: [systemd-devel] Normal user can ask status of services
On Sun, Aug 27, 2023 at 07:35:53PM +0200, Cecil Westerhof wrote: > Op zo 27 aug 2023 om 18:30 schreef Leon Fauster >: > > > Am 26.08.23 um 18:41 schrieb Cecil Westerhof: > > > Replying on google does not work as I am used to. It sends to the sender > > > instead of the group. > > > > > > Op za 26 aug 2023 om 18:36 schreef Cecil Westerhof > > > mailto:cldwester...@gmail.com>>: > > > > > > Op za 26 aug 2023 om 14:46 schreef Michael Biebl > > <mailto:mbi...@gmail.com>>: > > > > > > Am Sa., 26. Aug. 2023 um 09:44 Uhr schrieb Cecil Westerhof > > > mailto:cldwester...@gmail.com>>: > > > > > > > > I am at last implementing systemd timers. The service I > > > created can have its status queried by a normal user. I thought > > > I must have made a mistake. But when I do: > > > > systemctl status cron > > > > > > > > I get: > > > > ● cron.service - Regular background program processing > > daemon > > > > Loaded: loaded (/lib/systemd/system/cron.service; > > > enabled; preset: enabled) > > > > Active: active (running) since Sat 2023-08-19 > > > 18:12:04 CEST; 6 days ago > > > >Docs: man:cron(8) > > > >Main PID: 790 (cron) > > > > Tasks: 1 (limit: 17837) > > > > Memory: 91.0M > > > > CPU: 14min 3.110s > > > > CGroup: /system.slice/cron.service > > > > └─790 /usr/sbin/cron -f > > > > > > > > Warning: some journal files were not opened due to > > > insufficient permissions. > > > > > > > > Is this the expected behaviour? > > > > If not: what could be wrong with my system? > > > > > > > > This is on Debian 11. > > > > > > Reading system logs is a privileged operation. > > > > > > You can grant this privilege to individual users by adding them > > > to the > > > systemd-journal (or adm) group. > > > > > > Adding users to the adm will grant them additional privileges, > > > so be careful. > > > > > > > > > The user is in the lpadmin group, but not in systemd-journal, or adm > > > and still can ask the status. > > > Another reply indicates that this is normal. > > > > > > > > > Well, you can look at the process list anytime as normal user. So, what > > are you trying to accomplishing. Whats the goal? Hiding the process from > > the users? > > > > I was surprised that I could see it. And as I understand it, I am certainly > not the only one. One reply on my question was even that it is a privileged > operation and should not be possible without a group added to the user > which was not added to the user. > I agree that you can find out everything with ps, but that is a lot more > work. > I was just surprised that it was possible —and again I am far from the only > one—, I just wanted to check it out and now I know it is expected behaviour. > Better to ask a 'dump' question than staying ignorant I think. Also access to other users' stuff in /proc can be disabled by a mount option (hidepid=2). -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature
Re: [systemd-devel] deprecating Forward-Secure Sealing (FSS) in the journal
On Sun, Jul 30, 2023 at 08:35:24PM +0100, Dave Howorth wrote: > On Sun, 30 Jul 2023 11:52:34 -0400 > Demi Marie Obenour wrote: > > On Thu, Jul 27, 2023 at 08:10:41AM +, Zbigniew Jędrzejewski-Szmek > > wrote: > > > Hi, > > > > > > I'd like to start $subject. First, we'd just add an entry in NEWS > > > and make the key generation code print a warning, but then in a > > > release or few remove the code. > > > > > > See > > > https://github.com/systemd/systemd/pull/28433/commits/1ecd1a994733d. > > > > > > If you're using FSS, please speak up. > > > > > > Zbyszek > > > > What is the reason for this change? > > Does the comment in the commit not answer that? It does, sorry. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature
Re: [systemd-devel] deprecating Forward-Secure Sealing (FSS) in the journal
On Thu, Jul 27, 2023 at 08:10:41AM +, Zbigniew Jędrzejewski-Szmek wrote: > Hi, > > I'd like to start $subject. First, we'd just add an entry in NEWS > and make the key generation code print a warning, but then in a release > or few remove the code. > > See https://github.com/systemd/systemd/pull/28433/commits/1ecd1a994733d. > > If you're using FSS, please speak up. > > Zbyszek What is the reason for this change? -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature
Re: [systemd-devel] Running a non-idempotent command from udev
On Sat, Jul 15, 2023 at 09:00:03PM +0300, Mantas Mikulėnas wrote: > Is that "once per boot", "once per interface appearance", or "once per > physical NIC lifetime"? Can the command check its effects directly (i.e. > check whether a setting has been set, or whatever the task is)? Once per virtual NIC appearance. The catch is that the NIC can disappear and reappear very quickly, and the script must be run every time this happens. Furthermore, the script must wait for network-pre.target. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature
[systemd-devel] Running a non-idempotent command from udev
What is the appropriate solution for running a non-idempotent command from udev? One command needs to be run exactly once when a network interface appears, and another command needs to be run exactly once when a network interface disappears. Both commands need to run after network-pre.target, but that can be handled in the script themselves. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature
Re: [systemd-devel] Looking for guidance about starting a systemd service inside the initrd and having it persist after rootfs is mounted
On Thu, Jul 13, 2023 at 12:01:45PM -0400, Brian Masney wrote: > I am working on a project that has very strict boot time requirements > in order to have a custom service started within a set time period. > Waiting for the kernel to initialize the storage controller and mount > the root filesystem takes too much of the allocated time budget. > There's various boot speed optimizations that we are working on and > it's going to take a combination of multiple approaches. What kind of system is this? What does the time-critical service depend on? If this is a safety requirement (such as the backup camera in a car turning on fast enough), is Linux the correct choice for this application, or would a safety-certified RTOS be better option? -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature
