[systemd-devel] Ordering a service before remote-fs-pre.target makes it quite longer

Thomas HUMMEL thomas.hummel at pasteur.fr
Fri May 15 09:57:26 UTC 2020


On 14/05/2020 07:35, Andrei Borzenkov wrote:
> It does not match your graphs. Your service is apparently ordered after
> network-online.target (not after network.target) and startup is most
> certainly initiated before rsyslog.service. Not hat it explains anything
> but at least you need to provide accurate facts when you ask question.


Hello,

well this is odd as I didn't express myself such a dependency on 
network-online.target.

The only one I can think of comes indirectly from the 
Before=beegfs-client.service on the runs I did with 
beegfs-client.service enabled. In those conditions, the service which 
takes a long time has a Before=beegfs-client.service dependency which 
itself is ordered after network-online.target. But on the graphs I sent 
I see no beegfs-client so I do think I did send graphs with 
beegfs-client disabled, thus no explicit network-online.target dep...

> it is really outside of systemd scope. Systemd has no control
> over what your service does once ExecStart is spawned. You need to debug
> your service to find out what happens.

Of course. This was by no way a pointing against systemd.

My initial question was maybe I was ordering around remote-fs-pre.target 
in a nonsensical manner.

In other words : is it a bad practice to order a home made service 
before remote-fs-pre.target ?


Thanks for your help.

--

TH




More information about the systemd-devel mailing list