Judging by https://launchpad.net/~upstream-systemd-ci/+archive/ubuntu/systemd-ci/+packages,
it got updated about 15 hours ago and the "build check" action has been
failing with
```
The following packages have unmet dependencies:
kbd : Depends: console-setup but it is not going to be installed or
E: Unable to correct problems, you have held broken packages.
console-setup-mini but it is not going to be installed
```
since then
Read-only /var/tmp is more likely, because it's backed by a real device. /tmp
is (by default) backed by tmpfs, but it doesn't have to be. In both cases the
same consideration applies.
If we boot with read-only /var/tmp, any unit with PrivateTmp=yes would fail
because we cannot create the subdir under /var/tmp to mount the private directory.
But many services actually don't require /var/tmp (either because they only use
it occasionally, or because they only use /tmp, or even because they don't use the
temporary directories at all, and PrivateTmp=yes is used to isolate them from
the rest of the system).
To handle both cases let's create a read-only directory under /run/systemd and
mount it as the private /tmp or /var/tmp. (Read-only to not fool the service into
dumping too much data in /run.)
$ sudo systemd-run -t -p PrivateTmp=yes bash
Running as unit: run-u14.service
Press ^] three times within 1s to disconnect TTY.
[root@workstation /]# ls -l /tmp/
total 0
[root@workstation /]# ls -l /var/tmp/
total 0
[root@workstation /]# touch /tmp/f
[root@workstation /]# touch /var/tmp/f
touch: cannot touch '/var/tmp/f': Read-only file system
This commit has more changes than I like to put in one commit, but it's touching all
the same paths so it's hard to split.
exec_runtime_make() was using the wrong cleanup function, so the directory would be
left behind on error.
Let's add a catalog entry explaining further details.
Most importantly though: talk to PID 1 directly, via the private D-Bus
socket, so that this actually works correctly during early boot, where
D-Bus is not around.
Apparently systemd is no longer installed in fedora containers
by default
```
docker: Error response from daemon: OCI runtime create failed: container_linux.go:348:
starting container process caused "exec: \"/sbin/init\": stat /sbin/init: no such file or directory": unknown.
The command "$CI_MANAGERS/fedora.sh SETUP" failed and exited with 127 during .
```
The test would always fail with a long uname. In F33 this is right
now "5.8.0-0.rc2.20200622git625d3449788f.1.fc33.x86_64" which caused the
test to always fail.
Commit b0ca726585 "rpm: avoid hiding errors from systemd commands" remove hiding errors and output
for other macros, but did not do that for %sysusers_create_package and %tmpfiles_create_package.
This change syncs their behaviour with %sysusers_create and %tmpfiles_create
Signed-off-by: Mikhail Novosyolov <m.novosyolov@rosalinux.ru>
The last line in this macros was actually "SYSTEMD_INLINE_EOF " with a space at the end,
but the shell was instructed to look for a line without space.
Macros %sysusers_create_inline and %tmpfiles_create_inline did not have this mistake.
An example:
[root@rosa-2019 bind-server]# cat /etc/passwd | grep named
[root@rosa-2019 bind-server]# cat /tmp/bs
systemd-sysusers --replace=/usr/lib/sysusers.d/named.conf - <<SYSTEMD_INLINE_EOF >/dev/null 2>&1 || :
u named - "BIND DNS Server" /var/lib/named
g named - -
m named named
SYSTEMD_INLINE_EOF
[root@rosa-2019 bind-server]# sh /tmp/bs
/tmp/bs: line 5: warning: here-document at line 1 delimited by end-of-file (wanted `SYSTEMD_INLINE_EOF')
[root@rosa-2019 bind-server]# bash /tmp/bs
/tmp/bs: line 5: warning: here-document at line 1 delimited by end-of-file (wanted `SYSTEMD_INLINE_EOF')
[root@rosa-2019 bind-server]# bash --version
GNU bash, version 5.0.17(1)-release (x86_64-openmandriva-linux-gnu)
The user and group named were NOT created!
Now I remove the trailing space after "SYSTEMD_INLINE_EOF" and rerun:
[root@rosa-2019 bind-server]# sh /tmp/bs
[root@rosa-2019 bind-server]# tail -n 1 /etc/group
named❌485:named
[root@rosa-2019 bind-server]#
The user and group have been created correctly.
Signed-off-by: Mikhail Novosyolov <m.novosyolov@rosalinux.ru>
Currently systemd-user-runtime-dir does not create the files in
/run/user/$UID/systemd/inaccessible with the default SELinux label.
The user and role part of these labels should be based on the user
related to $UID and not based on the process context of
systemd-user-runtime-dir.
Since v246-rc1 (9664be199a) /run/user/$UID/systemd is also created by
systemd-user-runtime-dir and should also be created with the default
SELinux context.
This commit enables the microphone mute button and the screen rotate button, even if the latter is improperly linked. I have documented how to achieve this in https://wiki.archlinux.org/index.php/MSI_P15#Fn_Keys .
We never return anything higher than 63, so using "long unsigned"
as the type only confused the reader. (We can still use "long unsigned"
and safe_atolu() to parse the kernel file.)
We would refuse to print capabilities which were didn't have a name
for. The kernel adds new capabilities from time to time, most recently
cap_bpf. 'systmectl show -p CapabilityBoundingSet ...' would fail with
"Failed to parse bus message: Invalid argument" because
capability_set_to_string_alloc() would fail with -EINVAL. So let's
print such capabilities in hexadecimal:
CapabilityBoundingSet=cap_chown cap_dac_override cap_dac_read_search
cap_fowner cap_fsetid cap_kill cap_setgid cap_setuid cap_setpcap
cap_linux_immutable cap_net_bind_service cap_net_broadcast cap_net_admin
cap_net_raw cap_ipc_lock cap_ipc_owner 0x10 0x11 0x12 0x13 0x14 0x15 0x16
0x17 0x18 0x19 0x1a ...
For symmetry, also allow capabilities that we don't know to be specified.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1853736.
The call would always fail with:
systemd-userwork[780]: Failed to dlopen(libnss_systemd.so.2), ignoring: /usr/lib64libnss_systemd.so.2: cannot open shared object file: No such file or directory
Evgeny Vereshchagin