Kay Sievers [Sat, 31 Dec 2011 03:20:25 +0000 (04:20 +0100)]
logind: add 'login' subdir to include dirs
When separate 'builddirs', like with 'distcheck', are used, the generated
sources, like the '.c' files from 'gperf', are placed in the 'builddir' and
can not find the include headers in 'srcdir'.
Michal Schmidt [Sun, 18 Dec 2011 13:57:54 +0000 (14:57 +0100)]
log: never block on syslog in PID 1
Use a non-blocking syslog socket if logging from PID 1.
If sendmsg fails with EAGAIN, fall back to kmsg or console only for the
current message. Next message will try syslog again.
Michal Schmidt [Sun, 18 Dec 2011 13:58:10 +0000 (14:58 +0100)]
dbus: register to DBus asynchronously
Chen Jie observed and analyzed a deadlock. Assuming systemd-kmsg-syslogd
is already stopped, but rsyslogd is not started yet:
1. systemd makes a synchronous call to dbus-daemon.
2. dbus-daemon wants to write something to syslog.
3. syslog needs to be started by systemd.
... but cannot be, because systemd is waiting in 1.
Solve this by avoiding synchronous D-Bus calls. I had to write an async
bus registration call. Interestingly, D-Bus authors anticipated this, in
documentation to dbus_bus_set_unique_name():
> The only reason to use this function is to re-implement the equivalent
> of dbus_bus_register() yourself. One (probably unusual) reason to do
> that might be to do the bus registration call asynchronously instead
> of synchronously.
Lennart's comments from IRC:
> though I think this doesn't fix the problem in its entirety
> simply because dbus_connection_open_private() itself is still synchronous
> i.e. the connect() call behind it is not async
> I think I listed that issue actually on some D-Bus todo list
> i.e. to make dbus_connection_get() fully async
> but that's going to be hard
> so your patch looks good
So it may not be perfect, but it's clearly an improvement.
I did not manage to reproduce the original deadlock with the patch.
Michal Schmidt [Fri, 9 Dec 2011 14:24:04 +0000 (15:24 +0100)]
unit: fix false positive in check for unneeded unit
A freshly started unit A was immediately considered unneeded just because
unit B, which Requires A, was starting later in the transaction.
Fix it by looking not only at the state of B, but also at its pending job.
Michal Schmidt [Tue, 6 Dec 2011 00:14:36 +0000 (01:14 +0100)]
systemctl: print 'error' load state in red
Be consistent in coloring of load states in list-units and status.
Print only 'error' in red.
There are no 'banned' or 'failed' states. Do not color 'masked', it's
not an error.
Bill Nottingham [Tue, 22 Nov 2011 20:45:34 +0000 (15:45 -0500)]
Allow 'list-unit-files' to run with --root.
To do so, move the check for the bus to the bus-using portion of
list_unit_files(), and ensure that get_config_path doesn't abort when
checking the runtime path with --root.
Michal Schmidt [Sat, 3 Dec 2011 20:34:34 +0000 (21:34 +0100)]
service: stop the service if ExecStartPost ends with a failure
The handling of failures in ExecStartPost is inconsistent. If the
command times out, the service is stopped. But if the command exits
with a failure, the service keeps running.
It makes more sense to stop the service when ExecStartPost fails.
If this behaviour is not desired, the ExecStartPost command can be
prefixed with "-".
Michal Schmidt [Sat, 3 Dec 2011 01:13:30 +0000 (02:13 +0100)]
service: handle services with racy daemonization gracefully
There are a lot of forking daemons that do not exactly follow the
initialization steps as described in daemon(7). It is common that they
do not bother waiting in the parent process for the child to write the
PID file before exiting. The daemons' developers often do not perceive
this as a bug and they're unwilling to change.
Currently systemd warns about the missing PID file and falls back to
guessing the main PID. Being not quite deterministic, the guess can be
wrong with bad consequences. If the guessing is disabled, determinism is
achieved at the cost of losing the ability of noticing when the main
process of the service dies.
As long as it does not negatively affect properly written services,
systemd should strive for compatibility even with services with racy
daemonization. It is possible to provide determinism _and_ main process
supervision to them.
If the PID file is not there, rather than guessing and considering the
service running immediately after getting the SIGCHLD from the ExecStart
(or ExecStartPost) process, we can keep the service in the activating
state for a bit longer. We can use inotify to wait for the PID file to
appear. Only when it finally does appear and we read a valid PID from
it, we'll move the service to the running state. If the PID file never
appears, the usual timeout kicks in and the service fails.
projects / systemd / log