03.07.2020 12:09, Thomas HUMMEL пишет: > > > On 02/07/2020 20:48, Andrei Borzenkov wrote: > > >> Once again - dependencies in systemd are between jobs, not between units. > > Ok. I may have missed some docs but I've read several man sections > (likesystemd.service(5) and so on) as well as some 0pointer blog > articles) and I did experiment a lot. > I did not see this explained as clearly as you do here. At the opposite > it tends to focus on units (at least that's how I've read it the first > time), hence the confusion ? In fact, when reading those for the first > time I was left wanting to know more about transactions and jobs (which > are mentioned but really quickly). [Note that this is by no way a > criticism, just a/my feedback]. Watching debug logs gave me hints but > were not sufficient to come to the understanding you give me right now. >
systemd was designed to perform one single task - start well defined collection of units during system boot. When you consider this, it does not really matter whether you talk about unit or job dependency, end result is the same. I sincerely hope it was honest self delusion and not deliberate marketing trick to facilitate acceptance. Later systemd became abused as dynamic service manager, misleading documentation played not the last role in it. This thread is typical example. >> Rule 1: "B requires A" means "when starting B also submit start job for >> A and if this job failed *before we start activating B* cancel >> activation of B". If there is already start job for A for other reasons, >> the first part does nothing. > > Ok. What could be other reasons and do you mean this other reason would > itself have already added the A dependency and its management for itself ? > Unit could have been started (or at least requested to be started) due to dependencies of other units. >> >> Rule 2: "B after A" means "if start job for A is present in job queue >> wait for this job to complete before proceeding with start job for B". >> >> In your case on boot you have general Before dependency syslog.socket - >> sockets.target - basic.target - rsyslog.service and start request for >> both syslog.socket and rsyslog.service are queued. Start job for >> rsyslog.service is always delayed at least after basic.target (rule 2). >> At this point systemd already tried and failed to start syslog.socket, >> so rule 1 applies. > > Ok. So I guess my test when I, after reboot, run 4 ou 5 systemctl start > rsyslog.service and only the last one succeeds corresponds to this "race > condition" you described above ? > Yes. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
