[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