| Age | Commit message (Collapse) | Author |
|---|
|
Item glob processing will be useful for more than just removing.
|
|
|
|
remove_item -> remove_item_instance
remove_item_glob -> remove_item
|
|
For better safety. gcc can warn about missing values in switch statements.
|
|
It prevented the action from working without dbus.
|
|
|
|
|
|
|
|
systemd did not stop units marked as "StopWhenUnneeded=yes" when the requiring
unit was stopped on user's request.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=704197
|
|
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.
Also fix a copied&pasted comment.
|
|
PATH_MODIFIED worked internally for PID files detection, but was unusable
in units.
|
|
|
|
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.
|
|
Units that failed to load were never cleaned up. It was possible to
reach the 128K limit of units by attempting to load a bunch of nonsense.
Bug observed by Reartes Guillermo in
https://bugzilla.redhat.com/show_bug.cgi?id=680122
|
|
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.
|
|
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 "-".
|
|
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.
|
|
|
|
path_*() functions operate on "Path *p" and they do not touch PathSpec
internals directly.
pathspec_*() functions operate on "PathSpec *s". The PathSpec class will
be useful outside of path.c.
|
|
and strerror(-errno) was just wrong.
|
|
fgets() does not set errno on EOF.
|
|
As suggested by Bill Nottingham: rc.local is often used for frobbing the
network.
https://bugzilla.redhat.com/show_bug.cgi?id=754789
|
|
rc-local.service is pulled in by a generator only if the script is
executable. No need to check again.
|
|
rc-local.service acts as an ordering barrier even if its condition is
false, because conditions are evaluated when the service is about to be
started.
To avoid the ordering barrier in a legacy-free system, add a generator
to pull rc-local.service into the transaction only if the script is
executable.
If/when we rewrite SysV compatibility into a generator, this one can become
a part of it.
|
|
|
|
Both kmsg-syslogd and the real syslog service want to receive
SCM_CREDENTIALS. With socket activation it is too late to set
SO_PASSCRED in the services.
|
|
Since Linux 3.2 in order to receive SCM_CREDENTIALS it is not sufficient
to set SO_PASSCRED just before recvmsg(). The option has to be already
set when the sender sends the message.
With socket activation it is too late to set the option in the service.
It must be set on the socket right from the start.
See the kernel commit:
16e57262 af_unix: dont send SCM_CREDENTIALS by default
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=757628
|
|
Add an option to enable SO_PASSCRED for unix sockets.
|
|
Related-to: https://bugzilla.redhat.com/show_bug.cgi?id=750032
|
|
cron sets PAM_TTY to "cron" and it has been doing it for a long time.
It cannot be changed because user configurations may depend on it.
https://bugzilla.redhat.com/show_bug.cgi?id=727315
|
|
logind does not understand "other".
|
|
To give the administrator more hints about failures occuring in spawning
of commands than just the exit code, log the strerror.
All fds are closed, so reopen the log.
Related-to: https://bugzilla.redhat.com/show_bug.cgi?id=752901
|
|
The only caller currently checks if the result is non-zero,
so nothing changes there.
|
|
Several functions called from the "sd(EXEC)" process try to log messages
when all the file descriptors are already closed, including the logging
ones. The logging functions do not expect their fds to be closed and
they hit an assertion failure. The failure wants to be logged too,
so there is an infinite recursion, ended by a SIGSEGV.
When we close all fds, we must let log.c know about it.
|
|
The code should probably look like the statements above it.
Please verify, I just detected it using cppcheck.
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
|
|
Noticed by guzu.
|
|
The lack or green/red status marks on boot has been described by some
users as "critical", "dramatic", "dealbreaker", "showstopper". Seriously.
|
|
A service that drops its privileges may not be able to remove it when it
exits. The stale pidfile is not a problem as long as the service
carefully recognizes it on its next start.
systemd would produce a warning after the service exits:
PID ... read from file ... does not exist. Your service or init
script might be broken.
Silence the warning in this case. Still warn if this error is detected
when loading the pidfile after service start.
Noticed by Miroslav Lichvar in
https://bugzilla.redhat.com/show_bug.cgi?id=752396
|
|
Same change as the previous commit did for Fedora. fcrozat agreed.
|
|
rc-local.service should not be excluded from the default stdout logging.
Missing logs were noticed by Andrew McNabb in
https://bugzilla.redhat.com/show_bug.cgi?id=750032#c3
|
|
DefaultStandardOutput is syslog anyway. There's no reason to assume that
the administrator would want these units to be excluded when he configures
a different DefaultStandardOutput.
|
|
|
|
Zeroed .ut_tv values in wtmp confuse chkrootkit.
Reported and debugged by Norman Smith. This is based on his patch,
but modified to behave more like upstart did in F14 and cleaned up.
https://bugzilla.redhat.com/show_bug.cgi?id=743696
|
|
|
|
|
|
With these functions no caller ever passes anything else than 0
for 't' (meaning the current time will be used).
|
|
|
|
Some controllers have scaling problems when many empty cgroups exist.
Hence, as soon as we get a notification that a cgroup is empty, delete
it. This is also nice to keep the systemd-cgls output short.
|
|
|
|
|
