Re: [systemd-devel] local-fs and remote-fs targets / passive active units
On 5/5/20 7:41 PM, Andrei Borzenkov wrote: a) Before= does not pull anything anywhere. Yes I know sorry I did not use the correct term. I did not mean that. b) as you already found, by default every service is ordered after local-fs.target. You need DefalutDependencies=no if you want to start your service that early. Well, my first naive thought was to think : since fstab mount targets gets Before=local-fs.target, let's add this to my service which does locally mount some filesystem it creates. But it then made a cycle with system-tmpfiles-setup which depends on local-fs.target and my service which somehow got a dependency on sysinit.target which in turn depends on systemd-tmpfiles-setup... I'll think about another way to do it. Sorry for the useless bothering...and thanks again for your answer. -- TH ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] local-fs and remote-fs targets / passive active units
05.05.2020 18:15, Thomas HUMMEL пишет: > On 4/28/20 5:36 PM, Thomas HUMMEL wrote: > >> 3) regarding local-fs dans remote-fs targets : I'm not really sure if >> any fits in either passive or active units. > > Hello again, > > regarding local-fs.target : is it legit for a custom service unit to > pull it in with a Before=local-fs.target (no Wants or Requires) ? > a) Before= does not pull anything anywhere. b) as you already found, by default every service is ordered after local-fs.target. You need DefalutDependencies=no if you want to start your service that early. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] local-fs and remote-fs targets / passive active units
On 5/5/20 5:27 PM, Thomas HUMMEL wrote: On 5/5/20 5:15 PM, Thomas HUMMEL wrote: -> this seems to be like an actual run and not only the queuing of a job into the transaction which would be discarded afterwards when the cycle is discovered ? Ok I figure out this one : I was confusing the systemd-tmpfiles-setup.service from initrd and the one from the actual image. Still my question about why the cycle Sorry, I must have been blind : the cycle is obvious. and the explicit pulling of Before=local-fs.target stands. This leads me to the initial questions. Sorry for the confusion... -- TH ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] local-fs and remote-fs targets / passive active units
On 5/5/20 5:15 PM, Thomas HUMMEL wrote: -> this seems to be like an actual run and not only the queuing of a job into the transaction which would be discarded afterwards when the cycle is discovered ? Ok I figure out this one : I was confusing the systemd-tmpfiles-setup.service from initrd and the one from the actual image. Still my question about why the cycle and the explicit pulling of Before=local-fs.target stands. Thanks -- Thomas HUMMEL ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] local-fs and remote-fs targets / passive active units
On 4/28/20 5:36 PM, Thomas HUMMEL wrote: 3) regarding local-fs dans remote-fs targets : I'm not really sure if any fits in either passive or active units. Hello again, regarding local-fs.target : is it legit for a custom service unit to pull it in with a Before=local-fs.target (no Wants or Requires) ? For instance, I did create a simple oneshot test service (dodo.service) which just sleeps 20s stating Before=local-fs.target. I did that to emulate another service I created which formats an ssd and locally mount it (but outside of fstab so it would not get the automatic ordering dependency that systemd-fstab-generator gives) Note : this is on a statless host, so fstab states rootfs / tmpfs defaults,size=3500M 0 0 1) it seem to create lots of ordering cycles like this one (among many) dodo.service: Job systemd-tmpfiles-setup.service/start deleted to break ordering cycle starting with dodo.service/start I can't really see why even if I see that systemd-tmpfiles-setup has also a Before=local-fs.target ordering dependency ? 2) given the job ultimately gets deleted because of this cycle, I cannot understand why it seems to be exectuted anyway : [root@maestro-1002 systemd]# journalctl | grep -i systemd-tmpfiles-setup.service May 05 15:45:56 localhost systemd[1]: systemd-tmpfiles-setup.service: Installed new job systemd-tmpfiles-setup.service/start as 12 May 05 15:45:56 localhost systemd[1]: systemd-tmpfiles-setup.service: Passing 0 fds to service May 05 15:45:56 localhost systemd[1]: systemd-tmpfiles-setup.service: About to execute: /usr/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev May 05 15:45:56 localhost systemd[1]: systemd-tmpfiles-setup.service: Forked /usr/bin/systemd-tmpfiles as 863 May 05 15:45:56 localhost systemd[1]: systemd-tmpfiles-setup.service: Changed dead -> start May 05 15:45:56 localhost systemd[863]: systemd-tmpfiles-setup.service: Executing: /usr/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev May 05 15:45:57 localhost systemd[1]: systemd-tmpfiles-setup.service: Child 863 belongs to systemd-tmpfiles-setup.service. May 05 15:45:57 localhost systemd[1]: systemd-tmpfiles-setup.service: Main process exited, code=exited, status=0/SUCCESS May 05 15:45:57 localhost systemd[1]: systemd-tmpfiles-setup.service: Changed start -> exited May 05 15:45:57 localhost systemd[1]: systemd-tmpfiles-setup.service: Job systemd-tmpfiles-setup.service/start finished, result=done May 05 15:45:57 localhost systemd[1]: Got cgroup empty notification for: /system.slice/systemd-tmpfiles-setup.service May 05 15:46:31 maestro-1002.maestro.pasteur.fr systemd[1]: systemd-tmpfiles-setup.service: Changed dead -> exited -> this seems to be like an actual run and not only the queuing of a job into the transaction which would be discarded afterwards when the cycle is discovered ? However once the host booted, I can see that at least one tmpfile (in a tmpfiles.d config file) has indeed not be created as it should be (and as it actually is when /usr/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev is run manually). May 05 15:46:32 maestro-1002.maestro.pasteur.fr systemd[1]: systemd-tmpfiles-setup.service: Installed new job systemd-tmpfiles-setup.service/stop as 84 May 05 15:46:32 maestro-1002.maestro.pasteur.fr systemd[1]: systemd-tmpfiles-setup.service: Changed exited -> dead May 05 15:46:32 maestro-1002.maestro.pasteur.fr systemd[1]: systemd-tmpfiles-setup.service: Job systemd-tmpfiles-setup.service/stop finished, result=done May 05 15:46:34 maestro-1002.maestro.pasteur.fr systemd[1]: dodo.service: Found dependency on systemd-tmpfiles-setup.service/start May 05 15:46:34 maestro-1002.maestro.pasteur.fr systemd[1]: dodo.service: Job systemd-tmpfiles-setup.service/start deleted to break ordering cycle starting with dodo.service/start May 05 15:51:45 maestro-1002 systemd[1]: Preset files say disable systemd-tmpfiles-setup.service. Can you help me figure out my misunderstanding ? Thanks for your help -- Thomas HUMMEL ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] local-fs and remote-fs targets / passive active units
Hello, Reading systemd.special(7) and using systemctl show -p After,Before,Wants,Requires ..., I tried to figure out if my following understanding is true: doc says: - an active target is when the consumer pulls in the dependency (ex: network-online.target pulled in by nfs-mountd.service) - a passive target is when the producer pulls in the dependency (ex: network.target pulled in by NetworkManager.service and no other units is supposed to pull the passive unit in. 1) would it be true to consider that an active target always pulls in some units, which is why it is ultimately called "active" : it "does" (pull) something ? So an active unit would provide something to the consumers and would be on the "requirement" side of dependency type. 2) would it be true to consider that a passive target never pulls in any unit, which is why it is ultimately called "passive" as it just consists of some provider "publishing" a check point other units can order themselves upon ? This would be on the "ordering" side of dependeny type ? 3) regarding local-fs dans remote-fs targets : I'm not really sure if any fits in either passive or active units. I see that local-fs.target can be pulled in by sysinit.target and that dracut-pre-pivot.target can pull in remote-fs.target but to me those 2 targets would rather fit the passive unit category ? Thanks for your help -- Thomas HUMMEL ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
