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
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
