Re: [systemd-devel] [PATCH 0/6] RFC: Initial implementation of mount table handling using libmount kernelwatch
On Tue, 2020-07-28 at 16:13 +0200, Lennart Poettering wrote: > On Mo, 27.07.20 12:57, Ian Kent (ik...@redhat.com) wrote: > > > Further to my post about using the new mount table notifications in > > systemd I'd like to start by posting a few patches for discussion > > to > > hopefully get a better understanding of some aspects of how systemd > > mount unit state handling works, and also to get guidance on > > systemd > > coding style, and generally how I should be doing things in systemd > > as well as how best to debug problems. > > Thank you for working on this! > > We do reviews exclusively on github these days, could you please > submit this as PR on github? Thanks Lennart, will do. Although I was hoping for some generic discussion on this to set me going in the right direction. If that's not ok then I'll submit a PR when I think it's ready. Ian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journald not associating log messages with service
On Di, 28.07.20 12:12, Ian Pilcher (arequip...@gmail.com) wrote: > On 7/28/20 9:44 AM, Lennart Poettering wrote: > > Is the service short-lived? There's a race: if a process runs very > > quickly and logs journald might process the message after the process > > already exited, i.e. at a time where we can't read the cgroup off the > > process anymore. > > It is indeed a very short-lived "service". (All it does is check a > few things, write 1 value to a sysfs file, and exit.) > > > You can artifically delay your service's exit (sleep 10...) but it's > > still racy and sucks hard. You could issue the equivalent of > > "journalctl --sync" at the end of your program... > > Is there an API for that? Yes, but not in v219... That's just ancient, sorry. On newer version it's a Varlink API. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journald not associating log messages with service
On 7/28/20 9:44 AM, Lennart Poettering wrote: Is the service short-lived? There's a race: if a process runs very quickly and logs journald might process the message after the process already exited, i.e. at a time where we can't read the cgroup off the process anymore. It is indeed a very short-lived "service". (All it does is check a few things, write 1 value to a sysfs file, and exit.) You can artifically delay your service's exit (sleep 10...) but it's still racy and sucks hard. You could issue the equivalent of "journalctl --sync" at the end of your program... Is there an API for that? -- In Soviet Russia, Google searches you! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd.timer every X days?
On 7/28/20 11:07 AM, Mantas Mikulėnas wrote: I'd create a single raidcheck.service that runs daily and calls a script that itself determines which device to check, e.g. /dev/md$[dayofyear % 16]. That is the approach that I'm taking, although it means a fair bit of work. I need to parse a configuration file, do a bunch of date-related math, etc., as I don't really want to hard-code the number of RAID devices into a C program. -- In Soviet Russia, Google searches you! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd.timer every X days?
I'd create a single raidcheck.service that runs daily and calls a script that itself determines which device to check, e.g. /dev/md$[dayofyear % 16]. On Sun, Jul 26, 2020, 22:56 Ian Pilcher wrote: > My NAS has 16 MD RAID devices. I've created a simple service > (raidcheck@.service) that will trigger a check of the RAID device > identified by the argument. E.g., 'systemctl start raidcheck@md1' will > trigger the check of md1 (after checking that no other array is being > checked/synced, no arrays are degraded, etc.). > > It takes 6-8 hours to check one of these arrays, so I want to run one > check every night at 23:00. So (picking tonight as an arbitrary > starting point) md1 would run tonight, md2 would run tomorrow night, md3 > would run the following night ... all the way through md16. Then the > cycle would start over with md1. > > I had thought that I would be able to create 16 separate timers (one for > each device), each scheduled to trigger every 16 days at 23:00, starting > on a particular day. > > Looking through the systemd.timer(5) and systemd.time(7) man pages, > however, I haven't been able to figure out how to do this. Is it not > possible, or am I missing something? > > -- > > In Soviet Russia, Google searches you! > > > ___ > 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] systemd-repart with volatile root
I am still totally unable to make use of repart when the root is volatile... Is this intended, or not ? I know volatile-root service changes where the sysroot.mount ends up, for overlayfs, but this prevent repart from working because it can't find the underlying root block device anymore but only the overlay. It seems so, at least. This is my only theory for as to why it would print 'failed to discover root block device'. Any help / ideas are welcome On Fri Jul 17, 2020 at 4:38 PM CEST, Xogium wrote: > Hi, > as the subject says, I am trying to use repart to add a partition on a > block > device, from inside the initramfs. I also make use of overlayfs via > systemd-volatile-root to make it possible to write temporarily on the > root device. However it appears that systemd-repart and > systemd-volatile-root are both ran in parallel: http://ix.io/2rRi > This results in repart failing to find the root block device. > Would there be any way to have repart ran before systemd-volatile-root, > such > that it has time to finish modifying the real block device ? Adding > systemd-volatile-root on the Before= line in systemd-repart.service via > an > override is not enough since both units are of type simple. It is > started before > the volatile root unit, but they both ultimately end up running in > parallel once > again. > ___ > 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] Best practices for lots of similar units?
On Fr, 24.07.20 00:12, Roman Odaisky (r...@qwertty.com) wrote: > Hi All, > > Suppose I want to run a number of similar services that all require the same > boilerplate. How to avoid repeating myself when creating unit files? Three options: 1. Use templating, works great if you have a single parameter 2. Use drop-ins, i.e. define separate unit files for each instance, listing only the stuff that actually differs in each instance, and pull in the common stuff via a drop-in you symlink into the .d/ subdir of each instance. Covers things nicely, but of course only works to override or extend full lines. 3. Use a template engine/macro language of your choosing, such as m4 or so. > Let’s take a concrete example, websites. The boilerplate is as follows: > > [Unit] > After=syslog.target No need for this, it's not needed anymore today. > StandardError=syslog Also remove this line. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Running scripts after networkd has done its things
On Fr, 24.07.20 16:44, John Ioannidis (systemd-de...@tla.org) wrote: > I'm trying to be a good boy and migrate as much functionality as I can to > networkd. > > I'm happy with how networkd manages "internal" and "external" interfaces > and vlans for just setting up IPv4 addresses, but I still find support for > IPv6 to be woefully inadequate, at least for my environment; > netfilter/ipfilter support is also too rudimentary. What would be the > "correct" (whatever that means!) way to run scripts after networkd has > finished coming up, and before it has started going down? Essentially, I > want to emulate the up/down feature of ifupdown. See systemd.special(7), look for "network-online.target". Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journald not associating log messages with service
On Sa, 25.07.20 17:22, Ian Pilcher (arequip...@gmail.com) wrote: > I have a simple (non-forking) one-shot service that logs messages via > syslog. These messages are not being "associated" with the service > unit. I.e., they don't show up if I use journalctl's -u option > (although they are in the journal). > > UPDATE: I just tried using sd_journal_print, and I'm seeing exactly the > same behavior. > > This is a templated service, if that matters. > > Any idea what I can do to get these messages properly associated? Is the service short-lived? There's a race: if a process runs very quickly and logs journald might process the message after the process already exited, i.e. at a time where we can't read the cgroup off the process anymore. Sucks, and it would be great if the kernel could just send the cgroup info along... You can artifically delay your service's exit (sleep 10...) but it's still racy and sucks hard. You could issue the equivalent of "journalctl --sync" at the end of your program... Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 0/6] RFC: Initial implementation of mount table handling using libmount kernelwatch
On Mo, 27.07.20 12:57, Ian Kent (ik...@redhat.com) wrote: > Further to my post about using the new mount table notifications in > systemd I'd like to start by posting a few patches for discussion to > hopefully get a better understanding of some aspects of how systemd > mount unit state handling works, and also to get guidance on systemd > coding style, and generally how I should be doing things in systemd > as well as how best to debug problems. Thank you for working on this! We do reviews exclusively on github these days, could you please submit this as PR on github? See: https://systemd.io/CONTRIBUTING https://github.com/systemd/systemd/pulls Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd.timer every X days?
On So, 26.07.20 14:56, Ian Pilcher (arequip...@gmail.com) wrote: > My NAS has 16 MD RAID devices. I've created a simple service > (raidcheck@.service) that will trigger a check of the RAID device > identified by the argument. E.g., 'systemctl start raidcheck@md1' will > trigger the check of md1 (after checking that no other array is being > checked/synced, no arrays are degraded, etc.). > > It takes 6-8 hours to check one of these arrays, so I want to run one > check every night at 23:00. So (picking tonight as an arbitrary > starting point) md1 would run tonight, md2 would run tomorrow night, md3 > would run the following night ... all the way through md16. Then the > cycle would start over with md1. > > I had thought that I would be able to create 16 separate timers (one for > each device), each scheduled to trigger every 16 days at 23:00, starting > on a particular day. > > Looking through the systemd.timer(5) and systemd.time(7) man pages, > however, I haven't been able to figure out how to do this. Is it not > possible, or am I missing something? So what you are trying to do here is a mixture of calendar based scheduling and monotonic scheduling. You could schedule the first iteration via OnCalendar= and then schedule subsequent iterations via OnUnitActiveSec=, but it's sloppy, since first of all this will accumulate the latency of activation, and then as soon as you have a DST change things will go completely off. We might be able to extend our calendar language natively to support something like this, i.e. calendar expressions that use monotonic adjusted repetition values, but quite frankly I don't even know how such an expression language could look like. Maybe a workable way is to just enqueue a transient timer for the next iteration at the end (or beginning) of your service, i.e. use systemd-timer with some minimal shell scripting. i.e. systemd-run --on-calendar=`date --date=@$((\`date -u +%s\` + 16*24*60*60+12*60*60)) %d-%m-%y 23:00:00` … (totally untested, but you get the idea: add 16.5 days to the current unix day, then break that down to the day, and use that to re-enqueue a transient calendar event) Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Q: ExecStartPost and SuccessExitStatus
On Di, 28.07.20 15:50, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > Hi! > > I have a case where my main process has two success exit codes, and > I'd like to run the ExecStartPost only if the exit code was > 0. However as I understand the documentation any exit code listed > for SuccessExitStatus is considered successful. I also listed the > alternative success return code in RestartPreventExitStatus, but > that's probably not necessary. > If I don't list the alternative exit code as success, the service > will be flages as failed, I guess... > > How would you solve this problem? Dou you actually men ExecStartPost=? Or is this a typo and you mean ExecStopPost=? How does your service definition look like otherwise? You can query the exit code with "systemctl show -p ExecMainStatus --value ". Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Q: ExecStartPost and SuccessExitStatus
Hi! I have a case where my main process has two success exit codes, and I'd like to run the ExecStartPost only if the exit code was 0. However as I understand the documentation any exit code listed for SuccessExitStatus is considered successful. I also listed the alternative success return code in RestartPreventExitStatus, but that's probably not necessary. If I don't list the alternative exit code as success, the service will be flages as failed, I guess... How would you solve this problem? Regards, Ulrich ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] nested x-systemd.automount - parent always mounted
Am 28.07.20 um 12:05 schrieb Lennart Poettering: > On Di, 28.07.20 02:02, Reindl Harald (h.rei...@thelounge.net) wrote: > >> Hi >> >> is this a kernel limitation or could systemd act better by *not* mount >> /boot unconditional becasue of the inherited /boot/efi? > > I think the kernel could theoretically support that, but we don't > right now, and I am not sure the usecase is strong enough, since it > makes idle detection pretty weird too... > > It's one of the reasons why we recommend to mount the ESP to /efi and > not submount it into /boot (why would one even, it's so weird that > many Linux distros do that...). It's also what > systemd-gpt-auto-generator does by default... > > My recommendation: mount the ESP to /efi, and maybe add a symlink from > /boot/efi → /efi, which makes things work with old code that insists > that the ESP must be available in /boot/efi... yeah, i buy that * umount /boot/efi; mkdir /efi; chmod 0755 /efi; rmdir /boot/efi; ln -s /efi /boot/efi * edit fstab * reboot [root@firewall:~]$ ls /boot/ total 30M lrwxrwxrwx 1 root root4 2020-07-28 12:12 efi -> /efi drwx-- 6 root root 1.0K 2020-07-13 20:30 grub2 drwxr-xr-x 3 root root 1.0K 2018-07-30 22:40 loader drwx-- 2 root root 12K 2013-10-13 22:52 lost+found dr-xr-xr-x. 5 root root 1.0K 2020-07-28 12:12 . dr-xr-xr-x. 20 root root 4.0K 2020-07-28 12:12 .. -rw-r--r-- 1 root root 167 2020-07-23 02:23 .vmlinuz-5.7.10-101.fc31.x86_64.hmac -rw--- 1 root root 15M 2020-07-28 02:15 initramfs-5.7.10-101.fc31.x86_64.img -rw--- 1 root root 5.0M 2020-07-23 02:25 System.map-5.7.10-101.fc31.x86_64 -rw-r--r-- 1 root root 217K 2020-07-23 02:25 config-5.7.10-101.fc31.x86_64 -rwxr-xr-x 1 root root 11M 2020-07-23 02:26 vmlinuz-5.7.10-101.fc31.x86_64 [root@firewall:~]$ ls /boot/efi/ total 26K drwxr-xr-x 4 root root 2.0K 2020-06-30 18:49 EFI drwxr-xr-x 3 root root 16K 1970-01-01 01:00 . dr-xr-xr-x. 20 root root 4.0K 2020-07-28 12:12 .. Jul 28 12:13:40 firewall.esx.vmware.local systemd-fsck[675]: boot: clean, 344/102400 files, 67904/409600 blocks Jul 28 12:13:40 firewall.esx.vmware.local systemd[1]: Started File System Check on /dev/disk/by-uuid/48ffb5f1-9ee0-4637-85ab-089e3c91c578. Jul 28 12:13:40 firewall.esx.vmware.local systemd[1]: Mounting /boot... Jul 28 12:13:40 firewall.esx.vmware.local kernel: EXT4-fs (sda3): mounted filesystem without journal. Opts: discard Jul 28 12:13:40 firewall.esx.vmware.local systemd[1]: Mounted /boot. Jul 28 12:13:43 firewall.esx.vmware.local systemd[1]: efi.automount: Got automount request for /efi, triggered by 681 (ls) Jul 28 12:13:43 firewall.esx.vmware.local systemd[1]: Starting File System Check on /dev/disk/by-uuid/8C0B-91C5... Jul 28 12:13:43 firewall.esx.vmware.local systemd-fsck[682]: fsck.fat 4.1 (2017-01-24) Jul 28 12:13:43 firewall.esx.vmware.local systemd-fsck[682]: /dev/sda1: 12 files, 3830/51091 clusters Jul 28 12:13:43 firewall.esx.vmware.local systemd[1]: Started File System Check on /dev/disk/by-uuid/8C0B-91C5. Jul 28 12:13:43 firewall.esx.vmware.local systemd[1]: Mounting /efi... Jul 28 12:13:43 firewall.esx.vmware.local systemd[1]: Mounted /efi. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] nested x-systemd.automount - parent always mounted
On Di, 28.07.20 02:02, Reindl Harald (h.rei...@thelounge.net) wrote: > Hi > > is this a kernel limitation or could systemd act better by *not* mount > /boot unconditional becasue of the inherited /boot/efi? I think the kernel could theoretically support that, but we don't right now, and I am not sure the usecase is strong enough, since it makes idle detection pretty weird too... It's one of the reasons why we recommend to mount the ESP to /efi and not submount it into /boot (why would one even, it's so weird that many Linux distros do that...). It's also what systemd-gpt-auto-generator does by default... My recommendation: mount the ESP to /efi, and maybe add a symlink from /boot/efi → /efi, which makes things work with old code that insists that the ESP must be available in /boot/efi... Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
