| Age | Commit message (Collapse) | Author |
|---|
|
|
|
In some cases the main/control PID of a service can be outside of the
services cgroups (for example, if logind readjusts the processes'
cgroup). In order to clarify this for the user show the main/control PID
in the cgroup tree nonetheless, but mark them specially.
|
|
|
|
|
|
|
|
|
|
|
|
Previously, we were brutally and onconditionally killing all processes
in a service's cgroup before starting the service anew, in order to
ensure that StartPre lines cannot be misused to spawn long-running
processes.
On logind-less systems this has the effect that restarting sshd
necessarily calls all active ssh sessions, which is usually not
desirable.
With this patch control processes for a service are placed in a
sub-cgroup called "control/". When starting a service anew we simply
kill this cgroup, but not the main cgroup, in order to avoid killing any
long-running non-control processes from previous runs.
https://bugzilla.redhat.com/show_bug.cgi?id=805942
|
|
|
|
appear
|
|
|
|
gettys are nowadays mostly autospawned and hence usually subject to
being shut down on isolate requests, since they are no dependency of any
other unit. This is a bad idea if the user isolates between
multi-user.graphical and graphical.target, hence exclude them from the
isolation.
This has the effect that gettys no longer cleaned up when
emergency.target is isolated, which might actualy be considered a
feature, even though it is a change from previous behaviour...
Note that the one getty that really matters (the one on tty1) is still
removed when isolating to emergency.target since it conflicts with
emergency.service.
|
|
|
|
Leave the env vars used in the container/initrd logic set for PID1, but
don't inherit them to any children.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This adds minimal hardware watchdog support to PID 1. The idea is that
PID 1 supervises and watchdogs system services, while the hardware
watchdog is used to supervise PID 1.
This adds two hardware watchdog configuration options, for the runtime
watchdog and for a shutdown watchdog. The former is active during normal
operation, the latter only at reboots to ensure that if a clean reboot
times out we reboot nonetheless.
If the runtime watchdog is enabled PID 1 will automatically wake up at
half the configured interval and write to the watchdog daemon.
By default we enable the shutdown watchdog, but leave the runtime
watchdog disabled in order not to break independent hardware watchdog
daemons people might be using.
This is only the most basic hookup. If necessary we can later on hook
up the watchdog ping more closely with services deemed crucial.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
interface
This logic can be turned off by defining SD_JOURNAL_SUPPRESS_LOCATION
before including sd-journal.h.
This also saves/restores errno in all logging functions, in order to be
useful as logging calls without side-effects.
This also adds a couple of __unlikely__ around the early checks in the
logging calls, in order to minimize the runtime impact.
|
|
journals to be traversed in parallel
|
|
|
|
udisks2 doesn't use /media anymore, instead mounts removable media in a
user-private directory beneath /run. /media is hence mostly obsolete and
hence it makes little sense to continue to mount a tmpfs to it.
Distributions should consider dropping the mount point entirely since
nothing uses it anymore.
|
|
|
|
Let's make things a bit easier to type, drop the systemd- prefix for
journalctl and loginctl, but provide the old names for compat.
All systemd binaries are hence now prefixed with "systemd-" with the
exception of the three primary user interface binaries:
systemctl
loginctl
journalctl
For those three we do provide systemd-xyz names as well, via symlinks:
systemd-systemctl → systemctl
systemd-loginctl → loginctl
systemd-journalctl → journalctl
We do this only for the *primary* user tools, in order to avoid
unnecessary namespace problems. That means tools like systemd-notify
stay the way they are.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
the socket in failure mode
An incoming connection that is immediately terminated might result in
getpeername() or a similar call failing. Hence it is quite possible that
while we are setting up an instantiated service for a socket we might
get an error and we shouldn't take this as hint to take the listening
socket down.
https://bugs.freedesktop.org/show_bug.cgi?id=45297
https://bugzilla.novell.com/show_bug.cgi?id=741590
|
|
|
|
https://bugzilla.redhat.com/show_bug.cgi?id=798760
(Note that this work is not complete yet, as the kernel seems to send us
useless data with SCM_SECURITY enabled)
|
|
we need to make sure that configuration data we expose via the bus ends
up in using getting an assert(). Even though configuration data is only
parsed from trusted sources we should be more careful with what we read.
|
|
|
|
|
|
|
