Bug 952334

Summary: Bacula fails to start under latest systemd due to "syslog.target" failure.
Product: [Fedora] Fedora Reporter: Michal Schmidt <mschmidt>
Component: baculaAssignee: Simone Caronni <negativo17>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: andreas, fschwarz, gwync, jason.donald.burgess, johannbg, lnykryn, metherid, mschmidt, msekleta, negativo17, notting, phracek, plautrba, systemd-maint, vanmeeuwen+fedora, vpavlin, zbyszek
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 951957 Environment:
Last Closed: 2013-05-11 16:51:51 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Michal Schmidt 2013-04-15 17:20:53 UTC
+++ 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).

Comment 1 Simone Caronni 2013-04-15 20:24:10 UTC
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

Comment 2 Michal Schmidt 2013-04-16 08:45:31 UTC
(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.

Comment 3 Simone Caronni 2013-04-16 09:34:25 UTC
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

Comment 4 Fedora Update System 2013-04-17 13:24:29 UTC
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

Comment 5 Fedora Update System 2013-04-17 13:24:56 UTC
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

Comment 6 Fedora Update System 2013-04-17 13:25:26 UTC
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

Comment 7 Jason Burgess 2013-04-19 11:55:57 UTC
FC18 update confirmed to be working now.

Comment 8 Simone Caronni 2013-04-19 12:05:47 UTC
Thanks for reporting!

Please give karma in Bodhi.

Comment 9 Fedora Update System 2013-04-26 23:56:38 UTC
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.

Comment 10 Fedora Update System 2013-04-27 00:13:17 UTC
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.

Comment 11 Fedora Update System 2013-04-27 03:03:37 UTC
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.