Bug 68553 - duplicate log in systemd environment
Summary: duplicate log in systemd environment
Status: RESOLVED DUPLICATE of bug 61399
Alias: None
Product: dbus
Classification: Unclassified
Component: core (show other bugs)
Version: 1.5
Hardware: Other All
: medium normal
Assignee: Havoc Pennington
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-26 04:44 UTC by Chengwei Yang
Modified: 2013-08-27 10:58 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Chengwei Yang 2013-08-26 04:44:39 UTC
The log of dbus-daemon always printed twice through systemd because an logical error. In systemd environment, regardless whether dbus-daemon is forked or not, it shouldn't print error to stderr but only syslog, because systemd implemented syslog. Otherwise, the log of dbus printed to stderr and syslog will both catched by systemd journal. And then duplicated like below.

...
Aug 23 11:11:52 localhost.bj.intel.com dbus[282]: [system] Successfully activated service 'org.freedesktop.PolicyKit1'
Aug 23 11:11:52 localhost.bj.intel.com dbus-daemon[282]: dbus[282]: [system] Successfully activated service 'org.freedesktop.PolicyKit1'
Aug 23 11:11:52 localhost.bj.intel.com dbus-daemon[282]: dbus[282]: [system] Activating service name='org.freedesktop.ModemManager' (using servicehelper)
Aug 23 11:11:52 localhost.bj.intel.com dbus[282]: [system] Activating service name='org.freedesktop.ModemManager' (using servicehelper)
Aug 23 11:11:52 localhost.bj.intel.com dbus-daemon[282]: dbus[282]: [system] Activating via systemd: service name='org.bluez' unit='dbus-org.bluez.service'
Aug 23 11:11:52 localhost.bj.intel.com dbus[282]: [system] Activating via systemd: service name='org.bluez' unit='dbus-org.bluez.service'
...

The second duplicate one is printed to stderr but also catched by systemd journal.
Comment 1 Chengwei Yang 2013-08-26 06:21:05 UTC
OK, this is invalid since 1.7.2. though the argument of is_daemon of _dbus_init_system_log() is a little misleading. In fact, it's is_test.
Comment 2 Simon McVittie 2013-08-27 09:41:37 UTC
There was a reason why I called it is_daemon, but I can't remember it right now...
Comment 3 Simon McVittie 2013-08-27 10:58:05 UTC
(In reply to comment #1)
> OK, this is invalid since 1.7.2. though the argument of is_daemon of
> _dbus_init_system_log() is a little misleading. In fact, it's is_test.

No, if anything it's more like !is_test - dbus-daemon sets it TRUE and the regression test sets it FALSE.

It appears I used is_daemon as a short form of "is a daemon whose stderr would go to the Journal if we are running under systemd", which is a bit long for a variable name :-)

Rationale for that naming, rather than is_test with the opposite sense: imagine we added another daemon (perhaps a daemon used to implement service activation?) with syslog support, and a command-line tool with syslog support. For correct results, we would probably want the other daemon to call _dbus_init_system_log (TRUE) like dbus-daemon does, and we would want the command-line tool to call _dbus_init_system_log (FALSE) like the tests do.

*** This bug has been marked as a duplicate of bug 61399 ***


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.