| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
On 32bit, refuse large offsets. Once https://gitlab.com/cryptsetup/cryptsetup/issues/359
is resolved, we should switch to the new api, whatever it is.
Fixes #7677.
|
|
We need to connect to hostnamed, so a private bus connection is no good.
It'd be simpler to use the normal bus connection unconditionally, but
that'd mean that e.g. systemd-analyze set-log-level might not work in
emergency mode. So let's keep trying to use the private connection except
for "plot".
Fixes #7667.
|
|
Kernel 3.10 compat
|
|
Since systemd v236, several Arch users complained that
systemd-cryptsetup-generator exits with an OOM error and that it
prevents the boot from continuing.
Investigating the diff of cryptsetup-generator between v235 and v236 I
noticed that create_disk allowed for the `password` and `filtered`
variables to be NULL (they're handled with `strempty()`) but not their
`*_escaped` versions, and returned OOM errors in those cases.
Fix this by checking that the input string is non-NULL before deciding
that `specifier_escape` had an OOM error.
I could not test this fix myself, but some users have reported success.
Downstream bug: https://bugs.archlinux.org/task/56733
|
|
Also include missing.h in dissect-image.c to pick it up.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Up until now, the behaviour in systemd has (mostly) been to silently
ignore failures to action unit directives that refer to an unavailble
controller. The addition of AssertControlGroupController and its
conditional counterpart allow explicit specification of the desired
behaviour when such a situation occurs.
As for how this can happen, it is possible that a particular controller
is not available in the cgroup hierarchy. One possible reason for this
is that, in the running kernel, the controller simply doesn't exist --
for example, the CPU controller in cgroup v2 has only recently been
merged and was out of tree until then. Another possibility is that the
controller exists, but has been forcibly disabled by `cgroup_disable=`
on the kernel command line.
In future this will also support whatever comes out of issue #7624,
`DefaultXAccounting=never`, or similar.
|
|
let's split up main() into more functions, to make it digestable
|
|
Otherwise, setting udev_log=debug in /etc/udev/udev.conf has no effects since
systemd-udevd is built with LOG_REALM=LOG_REALM_UDEV.
However using LOG_REALM_UDEV (for libudev_core) reveals another similar bug for
udevadm which should also define LOG_REALM_UDEV.
|
|
Slice cleanups and systemd-mount --owner
|
|
|
|
Let's remove a bit redundancy, and list variables of the same
type/category in one declaration line.
|
|
And let's optimize it a tiny bit, by only iterating through the argument
list once, instead of twice.
|
|
|
|
This code is executed before we parse command line/configuration
parameters, hence let's not use arg_system to figure our how to clean up
things, but instead PID == 1. Let's move that check inside of the
function, to make things a bit more robust abstract from the outside.
Also, let's add a log message about this, that was so far missing.
|
|
Let's hide this check inside the function and make it easier to follow
the general control flow of main().
|
|
Let's correct the error handling (the error is in errno, not r), and
let's add logging like the rest of the function has it.
|
|
Let's clarify that this is a non-issue, by downgrading it to LOG_WARN
and saying "ignoring" in the message.
|
|
Let's place them in initialize_runtime(), where they appear to fit best.
Effectively this is just a move a little bit down, swapping places with
log_execution_mode(), which should require neither call to be done
first.
Note that changes the conditionalization a bit for these calls, from
(PID == 1) to (arg_system && arg_action == ACTION_RUN). At this point this is pretty much the same
however, as we don't allow PID 1 without ACTION_RUN and without
arg_system set, safety_checks() ensures that.
|
|
It's part of finalizing our runtime parameters, hence let's move this
into load_configuration() after we loaded everything else. This is safe,
since we don't use it between the location where it was and where we
place it now yet.
|
|
More refactoring to make main() more digestable.
|
|
More refactoring to make main() more digestable
|
|
There's no point in duplicating the complex parse_env_file() invocation,
hence let's not do it.
|
|
It's kinda nice to hide this check inside of status_welcome() itself, so
that it handles all this on its own.
|
|
Let's merge two if blocks, and move log_close()/log_open() out of the
testing codepath, as there's no reason to have it there.
|
|
There's no need to do this within the block where logging is closed,
hence move it earlier, so that this block can be kept as small as
possible.
|
|
This just sets up some variables the loaded configuration will then
modify. Let's invoke it hence right before loading the configuration.
This moves the initialization just a tiny bit later, but that shouldn't
matter, since we never access it in-between.
|
|
It's sufficiently complex now, let's add our own function for this too.
|
|
Let's make sure that if we are PID 1 we are invoked in ACTION_RUN mode,
and in arg_system mode, as well as the opposite.
Everything else is untested and probably not worth supporting hence
let's bail out early if people try anyway.
|
|
More refactoring to make main() shorter.
|
|
More refactoring to make things more digestable.
|
|
Let's just move this up a few lines and unify the invocation.
|
|
No functional changes, just some refactoring to make main() more
digestable.
|
|
arguments/configuration files
Let's shorten main() a bit, and split out everything that loads our
configuration and runtime parameters into a function of its own.
No changes in behaviour.
|
|
Let's remove one memory allocation in the common path.
|
|
It doesn't save too much, but it's a common pattern so I think it's worth
to factor this out.
|
|
The kernel needs two numbers, but for the user it's most convenient to provide the
user name and have that resolved to uid and gid.
Right now the primary group of the specified user is always used. That's the most
common case anyway. In the future we can extend the --owner option to allow a group
after a colon.
[I added this before realizing that this will not be enough to be used for user
runtime directory. But this seems useful on its own, so I'm keeping this commit.]
|
|
No functional change.
|
|
|
|
|
|
This message would also be emitted at boot for any user with linger
enabled, so "logged in" is the wrong term to use.
|
|
Don't bother with removing the directory if we didn't create it.
|
|
(#7645)
This makes things a bit easier to read I think, and also makes sure we
always use the _unlikely_ wrapper around it, which so far we used
sometimes and other times we didn't. Let's clean that up.
|
|
core/path: implement transient path unit
|
