`Found ordering cycle on _SERVICE_` loops due to `local-fs.target` with `Requires` instead of `Wants` for mounts generated from `/etc/fstab`

[jeremy.rosen@xxxxxxxx (Jérémy Rosen)]

Ok, there are a couple of tools that have not be mentionned..

"systemd-analyze verify <service>" will check all sorts of stuff on a 
service, including checking recursively the deps and finding ordering cycles


systemctl list-dependencies can show ordering/req dependencies, up or 
down, recursively or not

to be completely honest, I never use dot for cycles.... I sometime 
read/grep the .dot file itself, but I never generate the image...

systemd-analyze is my favorite tool for that sort of problems

On 27/04/2018 06:01, Andrei Borzenkov wrote:
> 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel

-- 
SMILE <http://www.smile.eu/>

20 rue des Jardins
92600 Asnières-sur-Seine

	
*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS

email jeremy.rosen at smile.fr <mailto:jeremy.rosen at smile.fr>
phone +33141402967
url http://www.smile.eu

Twitter <https://twitter.com/GroupeSmile> Facebook 
<https://www.facebook.com/smileopensource> LinkedIn 
<https://www.linkedin.com/company/smile> Github 
<https://github.com/Smile-SA>


Découvrez lâ??univers Smile, rendez-vous sur smile.eu 
<http://smile.eu/?utm_source=signature&utm_medium=email&utm_campaign=signature>

eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20180427/11812ab4/attachment-0001.html>