Age | Commit message (Collapse) | Author |
|
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.
|
|
|
|
This separates user/group NSS lookups from host/network NSS lookups.
By default order all network mounts after host/network NSS lookups now,
and logind execution after user/group NSS lookups.
|
|
|
|
Especially in the case of --enable-split-usr, several units will point
to the wrong location for systemctl. Use @SYSTEMCTL@ which will always
contain the proper path.
|
|
|
|
|
|
The default setups should be a stateless as possible. /tmp as tmpfs is
the intended default for general purpose systems.
Small temporary files should not be stored on disk; lager files, or
files which should potentially survive a reboot, belong into /var/tmp.
Also catch up with some good old UNIX history.
More details are here:
https://fedoraproject.org/wiki/Features/tmp-on-tmpfs
|
|
Since a number of distribitions don't need this compat glue anymore drop
it from systemd upstream. Distributions which still haven't converted
to /run can steal these unit files from the git history if they need to.
|
|
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.
|
|
This is an S/MIME signed message
The mount of the securityfs filesystem is now performed in the main systemd
executable as it is used by IMA to provide the interface for loading custom
policies. The unit file 'units/sys-kernel-security.mount' has been removed
because it is not longer necessary.
Signed-off-by: Roberto Sassu <roberto.sassu@polito.it>
Acked-by: Gianluca Ramunno <ramunno@polito.it>
|
|
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 can fake SCM_CREDENTIALS
|
|
|
|
|
|
|
|
"activate" action
|
|
|
|
|
|
|
|
|
|
socket queues syslog messages from early boot on
|
|
replaced by journald
|
|
|
|
|
|
to needlessly abbreviate options unless they are very well established
|
|
|
|
|
|
|
|
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
|
|
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.
|
|
This patch adds support for the Mageia Linux distribution:
http://www.mageia.org/
Mageia is a fork of Mandriva although some divergence has already occured
and thus inclusion of these changes upstream allow us to (hopefully)
migrate more rapidly to the new standard approaches systemd offers.
Indeed, we already use the preferred mechanism of OS identification via
the /etc/os-release file rather than a distro specific variation.
This patch mostly mirrors the patch added previously for Mandriva
support. In addition to those original authors, this patch was mostly
written by Dexter Morgan with help from Colin Guthrie and Eugeni Dodonov.
|
|
remote-fs-pre.target is not a unit a user should ever explicitly enable.
Instead services which need to hook before network mounts should pull it
in.
|
|
|
|
since we need one fd per session (for logind) and one fd per service
(for stdout-syslog-bridge) increase the default rlimit a bit.
|
|
In order to ensure that bind mounts copy the final mount settings to the
new bind mount make the root and API FS mount options are applied before
the other file systems are mounted.
https://bugzilla.redhat.com/show_bug.cgi?id=718464
|
|
things unnecessarily
|
|
It was possible for the "ExecStartPre=-/bin/plymouth quit" to race
with plymouth-start.service which is pulled in indirectly by
basic.target -> sysinit.target.
The race left plymouth running on the terminal, making it unusable for
rescue purposes.
https://bugzilla.redhat.com/show_bug.cgi?id=710487
|
|
FUSE and configfs is very very similar, so handle both the same way.
|
|
systemd to refuse the rescue.service
|
|
mounted since we'll enumerate that fact anyway
|
|
Since hugetlbfs cannot be compiled as kernel module there's little point
in doing on-demand mounting via autofs for it.
|
|
Since the mqueue support cannot be built as a module there's little
benefit in having an autofs mount point set up for this.
|