Re: [systemd-devel] `Found ordering cycle on _SERVICE_` loops due to `local-fs.target` with `Requires` instead of `Wants` for mounts generated from `/etc/fstab`
26.04.2018 23:20, John Florian пишет: > On 2018-04-26 16:04, John Florian wrote: >> On 2018-04-25 04:53, Lennart Poettering wrote: >>> There have been requests in improving the cycle breaking algorithm, >>> but not much has been done in this area, since it's not clear what can >>> be done. Ultimately it's just polishing a broken situation, and >>> the better way out is to fix things properly, i.e. just correct the >>> cycle in the dependencies in the first place. >> >> Having been the author of numerous custom services that are intended >> to wedge into those provided by systemd/Fedora I've faced resolving >> these several times and I've never felt all that competent at the >> task. Lennart, you were immensely helpful on one occasion by pointing >> me to `systemctl show FOO` but even then hunting the problem down was >> far from simple (for me). I've done the dot/graphviz thing and found >> it just as useless to me as when I've tried applying it to Puppet's >> ordering/dependency looping. I'm not blaming those tools (or systemd) >> because I'm well aware much of the problem is my inability to use them >> effectively. The graphs always seem to be overly simple and revealing >> no problem or overly detailed and obscuring the problem. Compound >> that with "an arrow pointing this way means what exactly?" >> >> Is there anything else that could be done to make hunting these loops >> down easier? Is there an example of any product that has a similar >> situation where they excel at helping the developer? Or are we >> already there and I just need more practice? I'm sure part of my >> struggle is just not encountering these very regularly and integrating >> into much that I'm only partly familiar with, but the result is the >> same, trepidation and loathing. > > Since I hate to grumble w/o so much as offering any possible > suggestions... It seems like it might be helpful to have something like > `systemctl show` but only dumping the properties used for ordering and > dependencies. Ideally, only ordering OR dependencies as the case > warrants and for all units involved, but only those units. Well, you could use "systemctl show -p Id -p After -p Before" but the problem is to find the correct unit set. You really need something that simulates transaction and evaluates dependencies like systemd does it. Note that systemd should print offending cycle when it hits it: апр 27 06:54:14 bor-Latitude-E5450 systemd[1582]: foo.service: Found ordering cycle on foo.service/start апр 27 06:54:14 bor-Latitude-E5450 systemd[1582]: foo.service: Found dependency on bar.service/start апр 27 06:54:14 bor-Latitude-E5450 systemd[1582]: foo.service: Found dependency on baz.service/start апр 27 06:54:14 bor-Latitude-E5450 systemd[1582]: foo.service: Found dependency on foo.service/start апр 27 06:54:14 bor-Latitude-E5450 systemd[1582]: foo.service: Breaking ordering cycle by deleting job baz.service/start It would be helpful it if additionally printed kind of dependency (like foo.service is After bar.service) because this is by far not obvious for average user. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] `Found ordering cycle on _SERVICE_` loops due to `local-fs.target` with `Requires` instead of `Wants` for mounts generated from `/etc/fstab`
On 2018-04-26 16:04, John Florian wrote: On 2018-04-25 04:53, Lennart Poettering wrote: There have been requests in improving the cycle breaking algorithm, but not much has been done in this area, since it's not clear what can be done. Ultimately it's just polishing a broken situation, and the better way out is to fix things properly, i.e. just correct the cycle in the dependencies in the first place. Having been the author of numerous custom services that are intended to wedge into those provided by systemd/Fedora I've faced resolving these several times and I've never felt all that competent at the task. Lennart, you were immensely helpful on one occasion by pointing me to `systemctl show FOO` but even then hunting the problem down was far from simple (for me). I've done the dot/graphviz thing and found it just as useless to me as when I've tried applying it to Puppet's ordering/dependency looping. I'm not blaming those tools (or systemd) because I'm well aware much of the problem is my inability to use them effectively. The graphs always seem to be overly simple and revealing no problem or overly detailed and obscuring the problem. Compound that with "an arrow pointing this way means what exactly?" Is there anything else that could be done to make hunting these loops down easier? Is there an example of any product that has a similar situation where they excel at helping the developer? Or are we already there and I just need more practice? I'm sure part of my struggle is just not encountering these very regularly and integrating into much that I'm only partly familiar with, but the result is the same, trepidation and loathing. Since I hate to grumble w/o so much as offering any possible suggestions... It seems like it might be helpful to have something like `systemctl show` but only dumping the properties used for ordering and dependencies. Ideally, only ordering OR dependencies as the case warrants and for all units involved, but only those units. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] `Found ordering cycle on _SERVICE_` loops due to `local-fs.target` with `Requires` instead of `Wants` for mounts generated from `/etc/fstab`
On 2018-04-25 04:53, Lennart Poettering wrote: There have been requests in improving the cycle breaking algorithm, but not much has been done in this area, since it's not clear what can be done. Ultimately it's just polishing a broken situation, and the better way out is to fix things properly, i.e. just correct the cycle in the dependencies in the first place. Having been the author of numerous custom services that are intended to wedge into those provided by systemd/Fedora I've faced resolving these several times and I've never felt all that competent at the task. Lennart, you were immensely helpful on one occasion by pointing me to `systemctl show FOO` but even then hunting the problem down was far from simple (for me). I've done the dot/graphviz thing and found it just as useless to me as when I've tried applying it to Puppet's ordering/dependency looping. I'm not blaming those tools (or systemd) because I'm well aware much of the problem is my inability to use them effectively. The graphs always seem to be overly simple and revealing no problem or overly detailed and obscuring the problem. Compound that with "an arrow pointing this way means what exactly?" Is there anything else that could be done to make hunting these loops down easier? Is there an example of any product that has a similar situation where they excel at helping the developer? Or are we already there and I just need more practice? I'm sure part of my struggle is just not encountering these very regularly and integrating into much that I'm only partly familiar with, but the result is the same, trepidation and loathing. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] automount EFI system partition to /efi fails
On Mi, 25.04.18 13:24, Chris Murphy (li...@colorremedies.com) wrote: > What happens if /efi does not yet exist? I created it normally 'sudo > mkdir /efi' before modifying /etc/fstab to comment out /boot/efi > line. Nothing. The generator that establishes this automount point becomes a NOP unless: 1. /efi exists 2. /efi is empty 3. There's no mount listed for it in /etc/fstab Hence, if you want to make use of the automatic ESP mounting logic, then simply create /etc and all should be good. > So far as I know, installers don't create /efi (Fedora's installer > does not) so that would be a needed feature. And then also things that > modify /boot/efi need to be modified to use /efi instead. Some of this > is abstracted with symlinks, e.g. Fedora uses symlink grub2-efi.cfg -> > ../boot/efi/EFI/fedora/grub.cfg which is how grubby modifies it, but > that can be changed to grub2-efi.cfg -> ../efi/EFI/fedora/grub.cfg - > the bigger change is with the bootloader binaries needing updating, > those packages have to know to look at both locations for the > foreseeable future. Not too difficult, just a matter of doing it. The automatic /efi magic is an offer to distributions, that allows them to remove any kind of mount setup during distro install, and exposes exceptionally safe access to the ESP (because it is umounted shortly after every access though still appears mounted continously). However, it's really just that: an offer. Fedora doesn't use that by default last time I looked, though I wish it would. I guess this needs a champion who pushes this through the fedora changes bureaucracy. I'd recommend Fedora to create /efi at boot, and then maintain a compat symlink /boot/efi → ../efi to maintain compatibility with the status quo ante. If fedora were to make that change, I figure some RPM postinst script would have to rearrange things roughly like this: ```sh sed -i -e '/\/boot\/efi/d' /etc/fstab mkdir /efi umount /boot/efi rmdir /boot/efi ln -s ../efi /boot/efi ``` Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
