| Age | Commit message (Collapse) | Author |
|---|
|
Remove support for RequiresOverridable= and RequisiteOverridable=
|
|
|
|
|
|
generator: order initrd fsck-root after local-fs-pre
|
|
The initrd version of systemd-fsck-root.service must wait for
local-fs-pre.target just like systemd-fsck@.service to prevent
modifications to the filesystem prior to resuming from hibernation.
As-is my laptop routinely fails to resume due to fsck errors. The rest
of the time it is probably silently corrupting the filesystem.
Unlike normal boot, in the initrd systemd-fsck-root.service has no
special significance so it needs to be kept in sync with
systemd-fsck@.service. The name systemd-fsck-root.service is only used
to preserve state across switch-root.
|
|
nspawn: add ability to define additional, arbitrary veth links between host and container
|
|
|
|
The new switch operates like --network-veth, but may be specified
multiple times (to define multiple link pairs) and allows flexible
definition of the interface names.
This is an independent reimplementation of #1678, but defines different
semantics, keeping the behaviour completely independent of
--network-veth. It also comes will full hook-up for .nspawn files, and
the matching documentation.
|
|
core: use SD_EVENT_PRIORITY_NORMAL-n instead on -n
|
|
|
|
sd-ndisc: add missing parens
|
|
|
|
Otherwise the call might fail, because the error structure is already
initialized.
|
|
This allows us to shorten our code a bit.
|
|
Now that we don't have RequiresOverridable= and RequisiteOverridable=
dependencies anymore, we can get rid of tracking the "override" boolean
for jobs in the job engine, as it serves no purpose anymore.
While we are at it, fix some error messages we print when invoking
functions that take the override parameter.
|
|
As discussed at systemd.conf 2015 and on also raised on the ML:
http://lists.freedesktop.org/archives/systemd-devel/2015-November/034880.html
This removes the two XyzOverridable= unit dependencies, that were
basically never used, and do not enhance user experience in any way.
Most folks looking for the functionality this provides probably opt for
the "ignore-dependencies" job mode, and that's probably a good idea.
Hence, let's simplify systemd's dependency engine and remove these two
dependency types (and their inverses).
The unit file parser and the dbus property parser will now redirect
the settings/properties to result in an equivalent non-overridable
dependency. In the case of the unit file parser we generate a warning,
to inform the user.
The dbus properties for this unit type stay available on the unit
objects, but they are now hidden from usual introspection and will
always return the empty list when queried.
This should provide enough compatibility for the few unit files that
actually ever made use of this.
|
|
install: follow unit file symlinks in /usr, but not /etc when looking for [Install] data and more
|
|
Previously, the %u, %U, %s and %h specifiers would resolve to the user
name, numeric user ID, shell and home directory of the user configured
in the User= setting of a unit file, or the user of the manager instance
if no User= setting was configured. That at least was the theory. In
real-life this was not ever actually useful:
- For the systemd --user instance it made no sense to ever set User=,
since the instance runs in user context after all, and hence the
privileges to change user IDs don't even exist. The four specifiers
were actually not useful at all in this case.
- For the systemd --system instance we did not allow any resolving that
would require NSS. Hence, %s and %h were not supported, unless
User=root was set, in which case they would be hardcoded to /bin/sh
and /root, to avoid NSS. Then, %u would actually resolve to whatever
was set with User=, but %U would only resolve to the numeric UID of
that setting if the User= was specified in numeric form, or happened
to be root (in which case 0 was hardcoded as mapping). Two of the
specifiers are entirely useless in this case, one is realistically
also useless, and one is pretty pointless.
- Resolving of these settings would only happen if User= was actually
set *before* the specifiers where resolved. This behaviour was
undocumented and is really ugly, as specifiers should actually be
considered something that applies to the whole file equally,
independently of order...
With this change, %u, %U, %s and %h are drastically simplified: they now
always refer to the user that is running the service instance, and the
user configured in the unit file is irrelevant. For the system instance
of systemd this means they always resolve to "root", "0", "/bin/sh" and
"/root", thus avoiding NSS. For the user instance, to the data for the
specific user.
The new behaviour is identical to the old behaviour in all --user cases
and for all units that have no User= set (or set to "0" or "root").
|
|
|
|
[Install] data
Some distributions use alias unit files via symlinks in /usr to cover
for legacy service names. With this change we'll allow "systemctl
enable" on such aliases.
Previously, our rule was that symlinks are user configuration that
"systemctl enable" + "systemctl disable" creates and removes, while unit
files is where the instructions to do so are store. As a result of the
rule we'd never read install information through symlinks, since that
would mix enablement state with installation instructions.
Now, the new rule is that only symlinks inside of /etc are
configuration. Unit files, and symlinks in /usr are now valid for
installation instructions.
This patch is quite a rework of the whole install logic, and makes the
following addional changes:
- Adds a complete test "test-instal-root" that tests the install logic
pretty comprehensively.
- Never uses canonicalize_file_name(), because that's incompatible with
operation relative to a specific root directory.
- unit_file_get_state() is reworked to return a proper error, and
returns the state in a call-by-ref parameter. This cleans up confusion
between the enum type and errno-like errors.
- The new logic puts a limit on how long to follow unit file symlinks:
it will do so only for 64 steps at max.
- The InstallContext object's fields are renamed to will_process and
has_processed (will_install and has_installed) since they are also
used for deinstallation and all kinds of other operations.
- The root directory is always verified before use.
- install.c is reordered to place the exported functions together.
- Stricter rules are followed when traversing symlinks: the unit suffix
must say identical, and it's not allowed to link between regular units
and templated units.
- Various modernizations
- The "invalid" unit file state has been renamed to "bad", in order to
avoid confusion between UNIT_FILE_INVALID and
_UNIT_FILE_STATE_INVALID. Given that the state should normally not be
seen and is not documented this should not be a problematic change.
The new name is now documented however.
Fixes #1375, #1718, #1706
|
|
Instead, let the caller do that. Fix this by moving masked unit messages
into the caller, by returning a clear error code (ESHUTDOWN) by which
this may be detected.
|
|
|
|
Reported by Thomas Andersen.
|
|
build-sys: fix dependencies
|
|
update-man-list needs man/custom-entities.ent. Bug is nicely reproducible when
running make update-man-list.
|
|
man patch fix, and port journalctl --sync to use CLOCK_MONOTONIC timestamp files
|
|
core: remove SmackFileSystemRootLabel= again
|
|
|
|
Apparently, util-linux' mount command implicitly drops the smack-related
options anyway before passing them to the kernel, if the kernel doesn't
know SMACK, hence there's no point in duplicating this in systemd.
Fixes #1696
|
|
Adding 3/4th of the watchdog frequency as accuracy on top of 1/2 of the
watchdog frequency means we might end up at 5/4th of the frequency which
means we might miss the message from time to time.
Maybe fixes #1804
|
|
Previously, we'd rely on the mtime timestamps of the touch files to see
if our sync/rotation requests were already suppressed. This means we
rely on CLOCK_REALTIME timestamps. With this patch we instead store the
CLOCK_MONOTONIC timestamp *in* the touch files, and avoid relying on
mtime.
This should make things more reliable when the clock or underlying mtime
granularity is not very good.
This also adds warning messages if writing any of the flag files fails.
|
|
|
|
tests: fix unstoppable service
|
|
core: fix typo
|
|
|
|
[/etc/systemd/system/unstoppable.service:4] Unbalanced quoting,
ignoring: "/bin/echo 'I'm unstoppable!'"
|
|
Dependency engine improvements
|
|
|
|
3d793d29059a7ddf5282efa6b32b953c183d7a4d broke parsing of unit file
names that include backslashes, as extract_first_word() strips those.
Fix this, by introducing a new EXTRACT_RETAIN_ESCAPE flag which disables
looking at any flags, thus being compatible with the classic
FOREACH_WORD() behaviour.
|
|
test: fix failing test-socket-util when running with ipv6.disable=1 kernel param
|
|
For all units ensure there's an "Automatic Dependencies" section in the
man page, and explain which dependencies are automatically added in all
cases, and which ones are added on top if DefaultDependencies=yes is
set.
This is also done for systemd.exec(5), systemd.resource-control(5) and
systemd.unit(5) as these pages describe common behaviour of various unit
types.
|
|
Let's make the code a bit more explicit. Should not change execution
logic in any way.
|
|
callee, not caller
It's nicer to hide the check away in the various
xyz_add_default_dependencies() calls, rather than making it explicit in
the caller, and thus require deeper nesing.
|
|
Do so only on non-kdbus systems. And on non-kdbus systems don't bother
with .busname units.
|
|
basic.target
With this change services by default will no longer require
basic.target, but instead only after it it via After=basic.target.
However, they will still Require= on sysinit.target.
This has the benefit that when booting into emergency mode it is
relatively safe to actviate individual services, as this will not pull
the entirety of basic.target anymore, thus avoid everything listed in
sockets.target and suchlike. However, during the usual boot no change
should be noticed.
|
|
networkd: link - drop foreign config when configuring link
|
|
execute: Add new PassEnvironment= directive (v4)
|
|
@evverx brought up that test-execute runs under MANAGER_USER which
forwards all its environment variables to the services. It turns out it
only forwards those that were in the environment at the time of manager
creation, so this test was still working.
It was still possible to attack it by running something like:
$ sudo VAR1=a VAR2=b VAR3=c ./test-execute
Prevent that attack by unsetting the three variables explicitly before
creating the manager for the test case.
Also add comments explaining the interactions with MANAGER_USER and,
while it has some caveats, this tests are still valid in that context.
Tested by checking that the test running with the variables set from the
external environment will still pass.
|
|
Check the base case, plus erasing the list, listing the same variable
name more than once and when variables are absent from the manager
execution environment.
Confirmed that `sudo ./test-execute` passes and that modifying the test
cases (or the values of the set variables in test-execute.c) is enough
to make the test cases fail.
|
|
|
