This is a followup to: commit 1a37b9b904
It will fix denial messages from dbus-daemon between gdm and
systemd-logind on logging into GNOME due to this.
See the previous commit for more details.
Seems natural to be able to specify relative directory,
e.g. with journalctl -D. And even if, this should be checked
in front-end code, not in the library.
The 'kmod' builtin, like the 'firmware' and 'uaccess' builtins, does not set
any variables, so don't use IMPORT.
Notice that this changes the behaviour slightly: the processing of subsequent
rules for the event that loads a module will no longer wait for the module
loading to finish. This is not expected to cause any problems, but we should
keep an eye on it.
The properties will still be set in the udev database, but they will not be used
for setting the interface names. As for the other kernel commandline switches,
we allow it to be prefixed by 'rd.' to only apply in the initrd.
All Execs within the service, will get mounted the same
/tmp and /var/tmp directories, if service is configured with
PrivateTmp=yes. Temporary directories are cleaned up by service
itself in addition to systemd-tmpfiles. Directory which is mounted
as inaccessible is created at runtime in /run/systemd.
CIPSO is the Common IP Security Option, an IETF standard for setting
security levels for a process sending packets. In Smack kernels,
CIPSO headers are mapped to Smack labels automatically, but can be changed.
This patch writes label/category mappings from /etc/smack/cipso/ to
/sys/fs/smackfs/cipso2. The mapping format is "%s%4d%4d"["%4d"]...
For more information about Smack and CIPSO, see:
https://kernel.org/doc/Documentation/security/Smack.txt
.mount units coming from /proc/self/mountinfo file are
unmounted after local-fs.target is reached during shutdown.
Problem: .mount units popping up in mountinfo file are
added to systemd without any dependency. For that reason,
they are the first one to be unmounted during shutdown.
Whichever program mounted the file system deserves a
chance to also unmount it. This patch ensures that
/proc/self/mountinfo units will be unmounted after
local-fs.target during shutdown (if they haven't been
unmounted already)
Please see the documentation (e.g. pydoc3 systemd.daemon) for full
description. As usual, systemd._daemon wraps the raw interface, while
systemd.daemon provides the more pythonic API. sd_listen_fds,
sd_booted, sd_is_fifo, sd_is_socket, sd_is_socket_unix,
sd_is_socket_inet, sd_is_mq, and SD_LISTEN_FDS_START are currently
wrapped.
I need this to test half-installed socket-activated python
script, which requires PYTHONPATH and LD_LIBRARY_PATH set.
I assume that other people might find it useful to.
-E VAR passes through VAR from the environment, while
-E VAR=value sets VAR=value.
systemd-activate -E PYTHONPATH=/var/tmp/inst1/usr/lib64/python3.3/site-packages -E LD_LIBRARY_PATH=/var/tmp/inst1/usr/lib -l 2000 python3 -c 'from systemd.daemon import listen_fds; print(listen_fds())'
Strictly speaking this isn't necessary for the /run/systemd/seats/
directory, since that is created anyway as the first seat is found, and
seat0 is always found. But let's be explicit here, and also create the
sessions/ and users/ directories, so that people can always install
inotify watches from very early on, even when nobody logged in yet.
Previously we were testing whether /sys/fs/cgroup/systemd/ was a mount
point. This might be problematic however, when the cgroup trees are bind
mounted into a container from the host (which should be absolutely
valid), which might create the impression that the container was running
systemd, but only the host actually is.
Replace this by a check for the existance of the directory
/run/systemd/system/, which should work unconditionally, since /run can
never be a bind mount but *must* be a tmpfs on systemd systems, which is
flushed at boots. This means that data in /run always reflects
information about the current boot, and only of the local container,
which makes it the perfect choice for a check like this.
(As side effect this is nice to Ubuntu people who now use logind with
the systemd cgroup hierarchy, where the old sd_booted() check misdetects
systemd, even though they still run legacy Upstart.)
First, rename root-fs.target to initrd-root-fs.target to clarify its usage.
Mount units with "x-initrd-rootfs.mount" are now ordered before
initrd-root-fs.target. As we sometimes construct /sysroot mounts in
/etc/fstab in the initrd, we want these to be mounted before the
initrd-root-fs.target is active.
initrd.target can be the default target in the initrd.
(normal startup)
:
:
v
basic.target
|
______________________/|
/ |
| sysroot.mount
| |
| v
| initrd-root-fs.target
| |
| v
| initrd-parse-etc.service
(custom initrd services) |
| v
| (sysroot-usr.mount and
| various mounts marked
| with fstab option
| x-initrd.mount)
| |
| v
| initrd-fs.target
| |
\______________________ |
\|
v
initrd.target
|
v
initrd-cleanup.service
isolates to
initrd-switch-root.target
|
v
______________________/|
/ |
| initrd-udevadm-cleanup-db.service
| |
(custom initrd services) |
| |
\______________________ |
\|
v
initrd-switch-root.target
|
v
initrd-switch-root.service
|
v
switch-root
Back from old times when we developed systemd on non-systemd hosts we
still mounted the missing directories such as the cgroup stuff even when
running with a PID != 1. There's no point for that anymore, so let's
just do that if we are actually PID 1, and never otherwise.
https://bugs.freedesktop.org/show_bug.cgi?id=62354
https://bugs.freedesktop.org/show_bug.cgi?id=62085
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libsystemd-login.so:
undefined reference to `sd_listen_fds'
In ee465038ce 'build-sys: break dependency loop between
libsystemd-id128.la and -shared.la', a partial fix was applied, and
the use of functions from libsystemd-id128 was removed from
libsystemd-shared. Nevertheless, fdset.c was still using sd_listen_fds,
so libsystemd-login should be linked against libysystemd-daemon
or libsystemd-daemon-internal.
Tested-by: Elias Probst <mail@eliasprobst.eu>
journalctl -u unit is not very useful, because it doesn't show
systemd messages about starting, stopping, coredumps, etc,
like systemctl status unit does. Make it show the same
information using the same rules.
If somebody really want to see just messages from by the unit,
it is easy enough to use _SYSTEMD_UNIT=...
After that functions which add matches, show_journal_by_unit
and show_journal_by_user_unit, become nearly identical, so
I merged them into one function.
