machine: Add APIs CopyTo[Machine]WithFlags + CopyFrom[Machine]WithFlags
- Same API to those without `WithFlags` (except this can take flags)
- Initially, only a flag to allow replacing a file if it already exists
systemd-sysctl currently fails silently under any of these conditions:
- Missing permission to write a sysctl.
- Invalid sysctl (path doesn't exists).
- Ignore failure flag ('-' in front of the sysctl name).
Because of this behaviour, configuration issues can go unnoticed as
there is no way to detect those unless going through the logs.
--strict option forces systemd-sysctl to fail if a sysctl is invalid or
if permission are insufficient. Errors on sysctl marked as "ignore
failure" will still be ignored.
While Type=file works because it seems to be the default, the line gets
ignored as printed on the stderr output.
Use the correct value "regular-file" for the target type.
A read-only /usr may ship a sysext image by default and the user wants
to opt out. Currently it's not clear how to do this.
Document that a /dev/null symlink in /etc/extensions/ works to "mask" a
sysext image in a folder with lower precedence.
While overlaying files with a sysext can be useful, it may lead to
unexpected problems depending on when a process got started and which
version of the file it gets.
Call out that overlaying files is possible but don't recommend to make
use of it.
Previous implementation of disabling rapid commit was broken, and
dropped by 308d01f3c4.
Let's re-introduce the option in the correct way, as some servers seem
to return borked message when the solicit message contain the rapid
commit option.
Closes#24065.
I had trouble finding the right paragraphs, so I guess others might have
too. Hence let's add a tiny bit more structure by separating these two
parts out.
Do not go back to disk on each selinux access, but instead cache the
label off the inode we are actually reading. That way unit file contents
and unit file label we use for access checks are always in sync.
Based on discussions here:
https://github.com/systemd/systemd/pull/10023#issuecomment-1179835586
Replaces:
https://github.com/systemd/systemd/pull/23910
This changes behaviour a bit, because we'll reach and cache the label at
the moment of loading the unit (i.e. usually on boot and reload), but
not after relabelling. Thus, users must refresh the cache explicitly via
a "systemctl daemon-reload" if they relabelled things.
This makes the SELinux story a bit more debuggable, as it adds an
AccessSELinuxContext bus property to units that will report the label we are
using for a unit (or the empty string if not known).
This also drops using the "source" path of a unit as label source. if
there's value in it, then generators should manually copy the selinux
label from the source files onto the generated unit files, so that the
rule that "access labels are read when we read the definition files" is
upheld. But I am not convinced this is really a necessary, good idea.
Estimated battery discharge rate per hour is stored in :
/var/lib/systemd/sleep/battery_discharge_percentage_rate_per_hour
This value is used to determine the initial suspend interval. In case
this file is not available or value is invalid, HibernateDelaySec
interval is used.
After wakeup from initial suspend, this value is again estimated and
written to file if value is in range of 1-199.
Logs for reference : HibernateDelaySec=15min
- Updated in /etc/systemd/sleep.conf
Jul 14 19:17:58 localhost systemd-sleep[567]: Current battery charge
percentage: 100%
Jul 14 19:17:58 localhost systemd-sleep[567]: Failed to read discharge
rate from /var/lib/systemd/sleep/batt
ery_discharge_percentage_rate_per_hour: No such file or directory
Jul 14 19:17:58 localhost systemd-sleep[567]: Set timerfd wake alarm
for 15min
Jul 14 19:33:00 localhost systemd-sleep[567]: Current battery charge
percentage after wakeup: 90%
Jul 14 19:33:00 localhost systemd-sleep[567]: Attempting to estimate
battery discharge rate after wakeup from 15min sleep
Jul 14 19:33:00 localhost systemd-sleep[567]: product_id does not
exist: No such file or directory
Jul 14 19:33:00 localhost systemd-sleep[567]: Estimated discharge rate
39 successfully updated to
/var/lib/systemd/sleep/battery_discharge_percentage_rate_per_hour
Jul 14 19:33:00 localhost systemd-sleep[567]: Current battery charge
percentage: 90%
Jul 14 19:33:00 localhost systemd-sleep[567]: product_id does not
exist: No such file or directory
Jul 14 19:33:00 localhost systemd-sleep[567]: Set timerfd wake alarm
for 1h 48min 27s
Jul 14 21:21:30 localhost systemd-sleep[567]: Current battery charge
percentage after wakeup: 90%
Jul 14 21:21:30 localhost systemd-sleep[567]: Battery was not
discharged during suspension
It is not clear what "unprivileged user namespaces are available" means.
It could mean either that they are only usable, that is, enabled in the kernel,
or they have been enabled for the specific service. Referring to the
`PrivateUsers=` options makes it clear that the latter is meant.
Since the general generator logic was established in the rewrite in
07719a21b6, generators would always write to /tmp
by default. I think this not a good default at all, because generators write a
bunch of files and would create a mess in /tmp. And for debugging, one
generally needs to remove all the files in the output directory, because
generators will complain in the output paths are already present. Thus the
approach of disabling console logging and writing many files to /tmp when
invoked with no arguments is not nice, so let's disallow operation with no
args.
But when debugging, one generally does not care about the separate output dirs
(most generators use only one). Thus the general pattern I use is something
like:
rm -rf /tmp/x && mkdir /tmp/x && build/some-generator /tmp/{x,x,x}
This commit allows only one directory to be specified and simplifies this to:
rm -rf /tmp/x && mkdir /tmp/x && build/some-generator /tmp/x
This is useful to use "f" or "w" to write arbitrary binary files to
disk, or files with newlines and similar (for example to provision SSH
host keys and similar).
This imports credentials also via SMBIOS' "OEM vendor string" section,
similar to the existing import logic from fw_cfg.
Functionality-wise this is very similar to the existing fw_cfg logic,
both of which are easily settable on the qemu command line.
Pros and cons of each:
SMBIOS OEM vendor strings:
- pro: fast, because memory mapped
- pro: somewhat VMM independent, at least in theory
- pro: qemu upstream sees this as the future
- pro: no additional kernel module needed
- con: strings only, thus binary data is base64 encoded
fw_cfg:
- pro: has been supported for longer in qemu
- pro: supports binary data
- con: slow, because IO port based
- con: only qemu
- con: requires qemu_fw_cfg.ko kernel module
- con: qemu upstream sees this as legacy
DefaultSmackProcessLabel tells systemd what label to assign to its child
process in case SmackProcessLabel is not set in the service file. By
default, when DefaultSmackProcessLabel is not set child processes inherit
label from systemd.
If DefaultSmackProcessLabel is set to "/" (which is an invalid character
for a SMACK label) the DEFAULT_SMACK_PROCESS_LABEL set during compilation
is ignored and systemd act as if the option was unset.
Yu Watanabe
Max Gautier
Daan De Meyer
Alexander Wilson
David Tardon
Quentin Deslandes
codefiles
Luca Boccassi
Kai Lueke
Ulrich Ölmann
Lennart Poettering
Sonali Srivastava
Jan Janssen
Ansgar Burchardt
Vito Caputo
lastkrick
Zbigniew Jędrzejewski-Szmek
Andre Kalb
Łukasz Stelmach