This has been irritating me for quite a while: let's prefix these enum
values with a common prefix, like we do for almost all other enums.
No change in behaviour, just some renaming.
From the results of CIs in #11076, changing buffer size may cause
issue #10754. So, let's prohibit to change the size if it is already
bound.
This also reverts commit 986ab0d2dc.
If the socket fd is passed by PID1, then it is created by .socket unit
and we have already set sufficient option(s) for the socket.
So, let's not touch the passed socket.
We already *install* those as real files since de78fa9ba0.
Meson will start to copy symlinks as-is, so we would get dangling symlinks in
/usr/lib/systemd/user/.
I considered the layout in our sources to match the layout in the installation
filesystem (i.e. creating units/system/ and moving all files from units/ to
units/system/), but that seems overkill. By using normal files for both we get
some duplication, but those files change rarely, so it's not a big downside in
practice.
Fixes#9906.
In #10583, a unit file lives in ~/.config/systemd/user, and
'systemctl --runtime --user mask' is used to create a symlink in /run.
This symlink has lower priority than the config file, so
'systemctl --user' will happily load the unit file, and does't care about
the symlink at all.
But when asked if the unit is enabled, we'd look for all symlinks, find the
symlink in the runtime directory, and report that the unit is runtime-enabled.
In this particular case the fact that the symlink points at /dev/null, creates
additional confusion, but it doesn't really matter: *any* symlink (or regular
file) that is lower in the priority order is "covered" by the unit fragment,
and should be ignored.
Fixes#10583.
If the terminal is in graphical mode, the kernel will refuse to copy the fonts
and will return -EINVAL.
Also having the graphical mode in effect probably indicates that the terminal
is in used by another application and we shouldn't interfer in such cases.
The name argument in UnitFileInstallInfo (i->name) should always be a unit
file name, so the conditional always takes the 'else' branch.
The only call chain that links to find_symlinks_fd() is unit_file_lookup_state
→ find_symlinks_in_scope → find_symlinks → find_symlinks_fd. But
unit_file_lookup_state calls unit_name_is_valid(name), and then name is used
to construct the UnitFileInstallInfo object in install_info_discover, which just
uses the name it was given.
It would work when the generator was run by systemd, since generators
are always started in "/", but when running the generator for debugging
purposes the result would be ... different.
There should be no functional difference, except that the error message
is changd from "three or no arguments" to "zero or three arguments". Somehow
the inverted form always seemed strange.
umask() call is also dropped from run-generator. I think it wasn't dropped in
053254e3cb because the run generator was merged
around the same time.
RFC7766 section 4 states that in the absence of EDNS0, a response that
is too large for a 512-byte UDP packet will have the 'truncated' bit
set. The client is expected to retry the query over TCP.
Fixes#10264.
The parent slice is always filtered ahead of time from UNIT_BEFORE, so
checking if the current member is the same as the parent unit will never
pass.
I may also write a SLICE_FOREACH_CHILD macro to remove some more of the
parent slice checks, but this requires a bit of a rework and general
refactoring and may not be worth it, so let's just do this for now.
fdopen doesn't accept "e", it's ignored. Let's not mislead people into
believing that it actually sets O_CLOEXEC.
From `man 3 fdopen`:
> e (since glibc 2.7):
> Open the file with the O_CLOEXEC flag. See open(2) for more information. This flag is ignored for fdopen()
As mentioned by @jlebon in #11131.
It would be very wrong if any of the specfier printf calls modified
any of the objects or data being printed. Let's mark all arguments as const
(primarily to make it easier for the reader to see where modifications cannot
occur).
Previously, we'd immediately propagate unit state changes into any jobs
pending for them, always. With this we only do this if the manager is
out of the "reload" state. This fixes the problem #8803 tried to
address, by simply not completing jobs until after the reload (and thus
reestablishment of the dbus connection) is complete.
Note that there's no need to later on explicitly catch up with the
missed job state changes (i.e. there's no need to call
unit_process_job() later one explicitly). That's because for jobs in
JOB_WAITING state on deserialization all jobs are requeued into the run
queue anyway, and thus checked again if they can complete now. And for
JOB_RUNNING jobs unit_catchup() phase is going to trigger missed out
state changes *after* the reload complete anyway (after all that's what
distinguishes from unit_coldplug()).
Replaces: #8803
Zbigniew Jędrzejewski-Szmek
Yu Watanabe
Lennart Poettering
Michael Scherer
Franck Bui
Chris Down
Sam Morris
tibbling