+++ This bug was initially created as a clone of Bug #951957 +++ [...] (In reply to comment #0) > Requires=syslog.target network.target nss-lookup.target I'll re-add a dummy syslog.target unit file to F18 in order to unbreak bacula, but note that this Requires line is entirely wrong and should be fixed before F19. The listed targets are not 'acting' targets that would cause something useful to start when activated. They are 'provides-like' targets. Only the services that provide the respective features should pull these targets in. Other units are supposed to take advantage of the targets by using ordering dependencies. Additionally, syslog.target is obsolete even for ordering dependencies (but these would be harmless).
Hello, (In reply to comment #0) > (In reply to comment #0) > I'll re-add a dummy syslog.target unit file to F18 in order to unbreak > bacula, but note that this Requires line is entirely wrong and should be > fixed before F19. syslog.target is obsolete only on Fedora 18+? Does it need to be kept for Fedora 17 or it can be removed as well? I can remove it and push an update so you can remove systemd's dummy. > The listed targets are not 'acting' targets that would cause something > useful to start when activated. They are 'provides-like' targets. Only the > services that provide the respective features should pull these targets in. > Other units are supposed to take advantage of the targets by using ordering > dependencies. Can you explain this a bit more? I'm not sure I've understood. Should I remove the Requires line and use only the After directive as httpd's example here'? http://pkgs.fedoraproject.org/cgit/httpd.git/commit/httpd.service?id=42df2ed3fe9d840264e18fe05c91d699032edc5c Thanks, --Simone
(In reply to comment #1) > syslog.target is obsolete only on Fedora 18+? Does it need to be kept for > Fedora 17 or it can be removed as well? It's obsolete since Fedora 16, so you can remove it in 17 too. > I can remove it and push an update so you can remove systemd's dummy. Thanks. Though I'm going to keep the dummy in place for F18, because there are probably more units in use with a similar problem. > > The listed targets are not 'acting' targets that would cause something > > useful to start when activated. They are 'provides-like' targets. Only the > > services that provide the respective features should pull these targets in. > > Other units are supposed to take advantage of the targets by using ordering > > dependencies. > > Can you explain this a bit more? I'm not sure I've understood. Sure. First I'll explain the difference between requirement and ordering dependencies: systemd knows several types of dependencies between units. They can all be classified into two groups: - ordering dependencies: Before, After. - requirement dependencies: Requires, Wants, BindsTo, Requisite, Conflicts, ... When systemd receives a request to start a unit, it iterates recursively through the unit's requirement dependencies to produce a "transaction" (basically a set of units to be started or stopped). After some consistency checks of the transaction (such as making sure there are no contradictions, and no ordering cycles), the transaction is turned into a bunch of per-unit "jobs". A job says what operation (start, stop) should be performed on the unit. systemd processes the jobs in the order that satisfies the ordering dependencies of the respective units. In short, requirement dependencies tell systemd _what_ to start/stop. Ordering dependencies tell it _in_what_order_ to do this starting and stopping. Now to explain what I meant by the two classes of target units: Take swap.target for example. Let's have a look at some of the units that the target pulls into the transaction if I run "systemctl start swap.target": $ systemctl show -p Wants -p Requires swap.target Requires= Wants=dev-mapper-vg_deacon\x2dlv_swap.swap So on my system, starting swap.target would cause one *.swap unit to be activated. swap.target is an example of what I call an 'acting' target, because starting it causes something useful to start in addition to the target itself. basic.target, multi-user.target are 'acting' targets as well. As a different example, take network.target: $ systemctl show -p Wants -p Requires network.target Requires= Wants= As you can see, starting network.target does not in itself cause anything to happen. The purpose of network.target is different. There are a few services that "provide" network connectivity (network.service, NetworkManager.service, ...). They express this information in the following way: Wants=network.target Before=network.target This means that after the configured network-providing service (be it network.service or N.M.) is started, network.target will become active. Other units may want to order themselves after network.target to make sure they get started after the network capability is being provided. That's why I call network.target a 'provides-like' target. You won't find the terms 'acting target', 'provides-like target' in the systemd sources. There is no special handling of the two kinds of targets. The difference is merely in the intended usage of the targets. The intent can be deduced from the dependencies the target has. > Should I remove the Requires line and use only the After directive as > httpd's example here'? > > http://pkgs.fedoraproject.org/cgit/httpd.git/commit/httpd. > service?id=42df2ed3fe9d840264e18fe05c91d699032edc5c Yes, please. I suggest dropping this line too: StandardOutput=syslog (The stdout goes to the journal, which forwards it to the syslog by default anyway). As Jóhann pointed out in https://bugzilla.redhat.com/show_bug.cgi?id=951957#c3, one should be careful about Restart directives. We do not yet have a clear guideline on auto-restarting services in Fedora and traditionally we did not do this. Also Restart=on-failure may be preferred to Restart=always, because it can be dangerous to restart a service when it crashes. A crash implies the service is buggy and it may signal an attempt to exploit a vulnerability. Restarting the service gives the attacker another try.
Many thanks for taking the time for your kind explanation, it was really helpful. I've applied all the changes you mentioned [1] to bacula and the other packages I mantain. The Requires= directive seems a bit redundant to me though. [1] http://pkgs.fedoraproject.org/cgit/bacula.git/commit/?id=f0f03f222dda4373cfcee4b46f45bab362cbcd04
bacula-5.2.13-9.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/bacula-5.2.13-9.fc18
bacula-5.2.13-9.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/bacula-5.2.13-9.fc19
bacula-5.2.13-9.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/bacula-5.2.13-9.fc17
FC18 update confirmed to be working now.
Thanks for reporting! Please give karma in Bodhi.
bacula-5.2.13-9.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
bacula-5.2.13-9.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
bacula-5.2.13-9.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.