| Age | Commit message (Collapse) | Author |
|---|
|
Just as a matter of coding style: whenever we return successfully, let's
make sure all our return parameters are properly initialized to
something.
|
|
After generating the template name we can shortcut things and just call
unit_file_find_dirs() from inside itself, just with the new name and
save a good number of duplicate lines.
|
|
|
|
After all, most units won't have drop-in dirs, hence there's no point in
logging about that.
Fixes: #5252
|
|
rework WorkingDirectory= and RootDirectory= management for services
|
|
fstab-generator: Options= applies specifier expansion
|
|
Fixes: #5125
|
|
|
|
WorkingDirectory=~ is
Or actually, try to to do the right thing depending on what is
available:
- If we know $HOME from User=, then use that.
- If the UID for the service is 0, hardcode that WorkingDirectory=~ means WorkingDirectory=/root
- In any other case (which will be the unprivileged --user case), use
get_home_dir() to find the $HOME of the user we are running as.
- Otherwise fail.
Fixes: #5246 #5124
|
|
This reverts commit 8b89628a10af3863bfc97872912e9da4076a5929.
This broke #5246
|
|
|
|
|
|
Add new MountAPIVFS= boolean unit file setting + RootImage=
|
|
swap seccomp filter params on s390
|
|
Add a bit of code that tries to get the right parameter order in place
for some of the better known architectures, and skips
restrict_namespaces for other archs.
This also bypasses the test on archs where we don't know the right
order.
In this case I didn't bother with testing the case where no filter is
applied, since that is hopefully just an issue for now, as there's
nothing stopping us from supporting more archs, we just need to know
which order is right.
Fixes: #5241
|
|
When services are already enabled/disabled/masked, make sure
that --now still enforces start/stop.
|
|
(#5271)
The code make the following assertion: when freeing a event loop object
(usually it's done after exiting from the main event loop), no signal events
are still queued and are pending.
This assertion can be found in event_unmask_signal_data() with
"assert(!d->current);" assertion.
It appears that this assertion can be wrong at least in a specific case
described below.
Consider the following example which is inspired from udev: a process defines 3
source events: 2 are created by sd_event_add_signal() and 1 is created by
sd_event_add_post().
1. the process receives the 2 signals consecutively so that signal 'A' source
event is queued and pending. Consequently the post source event is also
queued and pending. This is done by sd_event_wait().
2. The callback for signal 'A' is called by sd_event_dispatch().
3. The next call to sd_event_wait() will queue signal 'B' source event.
4. The callback for the post source event is called and calls sd_event_exit().
5. the event loop is exited.
6. freeing the event loop object will lead to the assertion failure in
event_unmask_signal_data().
This patch simply removes this assertion as it doesn't seem to be a
bug if the signal data still reference a signal source at this point.
|
|
Same reasons as the previous patch.
|
|
Let's document that this is the case, and properly escape % when we
generate Options= in the generator.
Fixes: #5086
|
|
Add a new --pivot-root argument to systemd-nspawn, which specifies a
directory to pivot to / inside the container; while the original / is
pivoted to another specified directory (if provided). This adds
support for booting container images which may contain several bootable
sysroots, as is common with OSTree disk images. When these disk images
are booted on real hardware, ostree-prepare-root is run in conjunction
with sysroot.mount in the initramfs to achieve the same results.
|
|
The compiler warning is a false positive, since n_addresses is always
initialised on the success path from parse_argv(), but the compiler
obviously can’t work that out.
Fixes:
src/test/test-nss.c:426:9: warning: 'n_addresses' may be used uninitialized in this function [-Wmaybe-uninitialized]
|
|
On i386 we block the old mmap() call entirely, since we cannot properly
filter it. Thankfully it hasn't been used by glibc since quite some
time.
Fixes: #5240
|
|
Mask individual .wants/.requires symlinks
|
|
The flag is originally defined for "basic data partitions", but not for the
ESP. We reuse it for the various partitions defined by the Discoverable
Partitions Spec, but it isn't defined for the ESP, hence don't check for
it. Instead, do check for GPT_FLAG_NO_BLOCK_IO_PROTOCOL, as that flag
actually is defined for all partition types, and recommended to use by
the UEFI spec.
Fixes: #5218
|
|
Feb 04 22:35:42 systemd[1462]: foo.service: Wants dependency dropin /home/zbyszek/.config/systemd/user/foo.service.wants/diffname.service target ../barbar.service has different name
Feb 04 22:35:42 systemd[1462]: foo.service: Wants dependency dropin /home/zbyszek/.config/systemd/user/foo.service.wants/wrongname is not a valid unit name, ignoring
|
|
|
|
Fixes #1169.
Fixes #4830.
Example log errors:
Feb 04 22:13:28 systemd[1462]: foo.service: Wants dependency on empty_file.service is masked by /home/zbyszek/.config/systemd/user/foo.service.wants/empty_file.service, ignoring
Feb 04 22:13:28 systemd[1462]: foo.service: Wants dependency on masked.service is masked by /home/zbyszek/.config/systemd/user/foo.service.wants/masked.service, ignoring
|
|
dropins
Essentially, instead of sequentially adding deps based on all symlinks
encountered in .wants and .requires dirs for each name and each unit file load
path, iteratate over the load paths and unit names gathering symlinks, then
order them based on priority, and then iterate over the final list, adding
dependencies.
This patch doesn't change the logic too much, except that the order in which
dependencies are applied might be different. It wasn't defined before, so that
not really a change. Adding filtering on the symlinks is left for later
patches.
|
|
|
|
|
|
This reverts commit 0698b674920aa8a56dbd6a625729a35e5ae9c5df.
It was supposed to be merged, not squashed.
|
|
Fix handling of templates instantiated in /usr/lib.
All work to fix #5136.
|
|
before reloading, check that /run/systemd has enough space
|
|
No need to pass what we don't use.
|
|
it enabled
If a unit foobar@.service stored below /usr is instantiated via a
symlink foobar@quux.service also below /usr, then we should consider the
instance statically enabled, while the template itself should continue
to be considered enabled/disabled/static depending on its [Install]
section.
In order to implement this we'll now look for enablement symlinks in all
unit search paths, not just in the config and runtime dirs.
Fixes: #5136
|
|
Before this patch, if we'd encounter an instance or template symlink
while traversing a chain of symlinks we'd fill in the instance name and
retry the iteration. This makes no sense if the resulting name is
actually the same as we are coming from, as we'd just spin a couple of
times in the loop, until the UNIT_FILE_FOLLOW_SYMLINK_MAX iteration
limit is hit.
Fix this, by accepted the symlink as it is, if it identical to what we
filled in.
|
|
This slightly extends the roothash loading logic to first check for a
user.verity.roothash extended attribute on the image file. If it exists,
it is used as Verity root hash and the ".roothash" file is not used.
This should improve the chance that the roothash is retained when the
file is moved around, as the data snippet is attached directly to the
image file. The field is still detached from the file payload however,
in order to make sure it may be trusted independently.
This does not replace the ".roothash" file loading, it simply adds a
second way to retrieve the data.
Extended attributes are often a poor choice for storing metadata like
this as it is usually difficult to discover for admins and users, and
hard to fix if it ever gets out of sync. However, in this case I think
it's safe as verity implies read-only access, and thus there's little
chance of it to get out of sync.
|
|
This makes nspawn's logic of automatically discovering the root hash of
an image file generic, and then reuses it in systemd-dissect and in
PID1's RootImage= logic, so that verity is automatically set up whenever
we can.
|
|
directory for a service
This is similar to RootDirectory= but mounts the root file system from a
block device or loopback file instead of another directory.
This reuses the image dissector code now used by nspawn and
gpt-auto-discovery.
|
|
If the dissected image contains symlinks for the mount points we need we
need to make sure to follow this with chase_symlinks() so that we don't
leave the image.
|
|
ReadWritablePaths= work
5327c910d2fc1ae91bd0b891be92b30379c7467b claimed to add support for "+"
for prefixing paths with the configured RootDirectory=. But actually it
only implemented it in the backend, it did not add support for it to the
configuration file parsers. Fix that now.
|
|
conjunction with RootDirectory=
This adds a boolean unit file setting MountAPIVFS=. If set, the three
main API VFS mounts will be mounted for the service. This only has an
effect on RootDirectory=, which it makes a ton times more useful.
(This is basically the /dev + /proc + /sys mounting code posted in the
original #4727, but rebased on current git, and with the automatic logic
replaced by explicit logic controlled by a unit file setting)
|
|
The source_malloc field wants to be freed, too.
|
|
make RestrictAddressFamilies= officially a NOP on i386
|
|
If we can, use a memfd for serializing state during a daemon reload or
reexec. Fall back to a file in /run/systemd or /tmp only if memfds are
not available.
See: #5016
|
|
Let's add an extra safety check: before entering a reload/reexec, let's
verify that there's enough room in /run for it.
Fixes: #5016
|
|
|
|
it a NOP
See: #5215
|
|
Use `explicit_bzero`
|
|
CID #1370779.
|
