The advantage is that is the name is mispellt, cpp will warn us.
$ git grep -Ee "conf.set\('(HAVE|ENABLE)_" -l|xargs sed -r -i "s/conf.set\('(HAVE|ENABLE)_/conf.set10('\1_/"
$ git grep -Ee '#ifn?def (HAVE|ENABLE)' -l|xargs sed -r -i 's/#ifdef (HAVE|ENABLE)/#if \1/; s/#ifndef (HAVE|ENABLE)/#if ! \1/;'
$ git grep -Ee 'if.*defined\(HAVE' -l|xargs sed -i -r 's/defined\((HAVE_[A-Z0-9_]*)\)/\1/g'
$ git grep -Ee 'if.*defined\(ENABLE' -l|xargs sed -i -r 's/defined\((ENABLE_[A-Z0-9_]*)\)/\1/g'
+ manual changes to meson.build
squash! build-sys: use #if Y instead of #ifdef Y everywhere
v2:
- fix incorrect setting of HAVE_LIBIDN2
We would not consider symlinks in /etc/systemd/user/*.{wants,requires}/
towards the user unit being "enabled", because the symlinks were not
located in "config" paths. But this is confusing to users, since those units
are clearly enabled and will be started. So let's muddle the definition of
enablement a bit to include the paths only accessible to root when looking for
enabled user units.
Fixes#4432.
I think this matches the spirit of "indirect" well: the unit
*might* be active, even though it is not "installed" in the
sense of symlinks created based on the [Install] section.
The changes to test-install-root touch the same lines as in the previous
commit; the change in each case is from
assert_se(unit_file_get_state(...) >= 0 && state == UNIT_FILE_ENABLED)
to
assert_se(unit_file_get_state(...) >= 0 && state == UNIT_FILE_DISABLED)
to
assert_se(unit_file_get_state(...) >= 0 && state == UNIT_FILE_INDIRECT)
in the last two commits.
When a unit has a symlink that makes an alias in the filesystem,
but that name is not specified in [Install], it is confusing
is the unit is shown as "enabled". Look only for names specified
in Alias=.
Fixes#6338.
v2:
- Fix indentation.
- Fix checking for normal enablement, when the symlink name is the same as the
unit name. This case wasn't handled properly in v1.
v3:
- Rework the patch to also handle templates properly:
A template templ@.service with DefaultInstance=foo will be considered
enabled only when templ@foo.service symlink is found. Symlinks with
other instance names do not count, which matches the logic for aliases
to normal units. Tests are updated.
All those uses were correct, but I think it's better to be explicit.
Using implicit errno is too error prone, and with this change we can require
(in the sense of a style guideline) that the code is always specified.
Helpful query: git grep -n -P 'log_[^s][a-z]+\(.*%m'
Under specific circumstances it might happen that we can't figure out
where to place our symlinks, for example because we are supposed to
create them in the runtime directory but $XDG_RUNTIME_DIR is not set. In
this case, return -ENXIO instead of hitting an assert().
(Yeah, the error isn't very descriptive, but for now this should at
least be good enough to remove the assert() being hit.)
In some cases there might be unit symlinks in .wants/ or .requires/
directories even though the unit is otherwise fully removed. In this
case, don't fail removal, but still remove the symlinks.
This reworks the symlink marking logic to always add unit files that we
are missing to the changes list, but proceed with any symlink removal
for them. This way we'll still generate useful hints that a unit is
missing if you invoke "systemctl disable idontexist.service", but also
still remove any link to it.
Fixes: #4995
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.
Fixes:
```
touch hola.service
systemctl link $(pwd)/hola.service $(pwd)/hola.service
```
```
==1==ERROR: AddressSanitizer: attempting double-free on 0x60300002c560 in thread T0 (systemd):
#0 0x7fc8c961cb00 in free (/lib64/libasan.so.3+0xc6b00)
#1 0x7fc8c90ebd3b in strv_clear src/basic/strv.c:83
#2 0x7fc8c90ebdb6 in strv_free src/basic/strv.c:89
#3 0x55637c758c77 in strv_freep src/basic/strv.h:37
#4 0x55637c763ba9 in method_enable_unit_files_generic src/core/dbus-manager.c:1960
#5 0x55637c763d16 in method_link_unit_files src/core/dbus-manager.c:2001
#6 0x7fc8c92537ec in method_callbacks_run src/libsystemd/sd-bus/bus-objects.c:418
#7 0x7fc8c9258830 in object_find_and_run src/libsystemd/sd-bus/bus-objects.c:1255
#8 0x7fc8c92594d7 in bus_process_object src/libsystemd/sd-bus/bus-objects.c:1371
#9 0x7fc8c91e7553 in process_message src/libsystemd/sd-bus/sd-bus.c:2563
#10 0x7fc8c91e78ce in process_running src/libsystemd/sd-bus/sd-bus.c:2605
#11 0x7fc8c91e8f61 in bus_process_internal src/libsystemd/sd-bus/sd-bus.c:2837
#12 0x7fc8c91e90d2 in sd_bus_process src/libsystemd/sd-bus/sd-bus.c:2856
#13 0x7fc8c91ea8f9 in io_callback src/libsystemd/sd-bus/sd-bus.c:3126
#14 0x7fc8c928333b in source_dispatch src/libsystemd/sd-event/sd-event.c:2268
#15 0x7fc8c9285cf7 in sd_event_dispatch src/libsystemd/sd-event/sd-event.c:2627
#16 0x7fc8c92865fa in sd_event_run src/libsystemd/sd-event/sd-event.c:2686
#17 0x55637c6b5257 in manager_loop src/core/manager.c:2274
#18 0x55637c6a2194 in main src/core/main.c:1920
#19 0x7fc8c7ac7400 in __libc_start_main (/lib64/libc.so.6+0x20400)
#20 0x55637c697339 in _start (/usr/lib/systemd/systemd+0xcd339)
0x60300002c560 is located 0 bytes inside of 19-byte region [0x60300002c560,0x60300002c573)
freed by thread T0 (systemd) here:
#0 0x7fc8c961cb00 in free (/lib64/libasan.so.3+0xc6b00)
#1 0x7fc8c90ee320 in strv_remove src/basic/strv.c:630
#2 0x7fc8c90ee190 in strv_uniq src/basic/strv.c:602
#3 0x7fc8c9180533 in unit_file_link src/shared/install.c:1996
#4 0x55637c763b25 in method_enable_unit_files_generic src/core/dbus-manager.c:1985
#5 0x55637c763d16 in method_link_unit_files src/core/dbus-manager.c:2001
#6 0x7fc8c92537ec in method_callbacks_run src/libsystemd/sd-bus/bus-objects.c:418
#7 0x7fc8c9258830 in object_find_and_run src/libsystemd/sd-bus/bus-objects.c:1255
#8 0x7fc8c92594d7 in bus_process_object src/libsystemd/sd-bus/bus-objects.c:1371
#9 0x7fc8c91e7553 in process_message src/libsystemd/sd-bus/sd-bus.c:2563
#10 0x7fc8c91e78ce in process_running src/libsystemd/sd-bus/sd-bus.c:2605
#11 0x7fc8c91e8f61 in bus_process_internal src/libsystemd/sd-bus/sd-bus.c:2837
#12 0x7fc8c91e90d2 in sd_bus_process src/libsystemd/sd-bus/sd-bus.c:2856
#13 0x7fc8c91ea8f9 in io_callback src/libsystemd/sd-bus/sd-bus.c:3126
#14 0x7fc8c928333b in source_dispatch src/libsystemd/sd-event/sd-event.c:2268
#15 0x7fc8c9285cf7 in sd_event_dispatch src/libsystemd/sd-event/sd-event.c:2627
#16 0x7fc8c92865fa in sd_event_run src/libsystemd/sd-event/sd-event.c:2686
#17 0x55637c6b5257 in manager_loop src/core/manager.c:2274
#18 0x55637c6a2194 in main src/core/main.c:1920
#19 0x7fc8c7ac7400 in __libc_start_main (/lib64/libc.so.6+0x20400)
previously allocated by thread T0 (systemd) here:
#0 0x7fc8c95b0160 in strdup (/lib64/libasan.so.3+0x5a160)
#1 0x7fc8c90edf32 in strv_extend src/basic/strv.c:552
#2 0x7fc8c923ae41 in bus_message_read_strv_extend src/libsystemd/sd-bus/bus-message.c:5578
#3 0x7fc8c923b0de in sd_bus_message_read_strv src/libsystemd/sd-bus/bus-message.c:5600
#4 0x55637c7639d1 in method_enable_unit_files_generic src/core/dbus-manager.c:1969
#5 0x55637c763d16 in method_link_unit_files src/core/dbus-manager.c:2001
#6 0x7fc8c92537ec in method_callbacks_run src/libsystemd/sd-bus/bus-objects.c:418
#7 0x7fc8c9258830 in object_find_and_run src/libsystemd/sd-bus/bus-objects.c:1255
#8 0x7fc8c92594d7 in bus_process_object src/libsystemd/sd-bus/bus-objects.c:1371
#9 0x7fc8c91e7553 in process_message src/libsystemd/sd-bus/sd-bus.c:2563
#10 0x7fc8c91e78ce in process_running src/libsystemd/sd-bus/sd-bus.c:2605
#11 0x7fc8c91e8f61 in bus_process_internal src/libsystemd/sd-bus/sd-bus.c:2837
#12 0x7fc8c91e90d2 in sd_bus_process src/libsystemd/sd-bus/sd-bus.c:2856
#13 0x7fc8c91ea8f9 in io_callback src/libsystemd/sd-bus/sd-bus.c:3126
#14 0x7fc8c928333b in source_dispatch src/libsystemd/sd-event/sd-event.c:2268
#15 0x7fc8c9285cf7 in sd_event_dispatch src/libsystemd/sd-event/sd-event.c:2627
#16 0x7fc8c92865fa in sd_event_run src/libsystemd/sd-event/sd-event.c:2686
#17 0x55637c6b5257 in manager_loop src/core/manager.c:2274
#18 0x55637c6a2194 in main src/core/main.c:1920
#19 0x7fc8c7ac7400 in __libc_start_main (/lib64/libc.so.6+0x20400)
SUMMARY: AddressSanitizer: double-free (/lib64/libasan.so.3+0xc6b00) in free
==1==ABORTING
```
Closes#5015
Easily reproducible:
1) systemctl mask foo
2) systemctl unmask foo foo
The problem here is that the *i that is put into todo[] is later freed
in strv_uniq(), which is not directly visible from this patch. Somewhere
further in the code, the string that *i pointed to is freed again. That
happens only when multiple services with the same name/path are specified.
This permits "systemctl enable" and "systemctl add-wants" on template
units without any specifications of an instance name, neither specified
on the command line, nor specified in DefaultInstance= field of the
[install] section.
Fixes: #3473
It may be desired by users to know what targets a particular service is
installed into. Improve user friendliness by teaching the is-enabled
command to show such information when used with --full.
This patch makes use of the newly added UnitFileFlags and adds
UNIT_FILE_DRY_RUN flag into it. Since the API had already been modified,
it's now easy to add the new dry-run feature for other commands as
well. As a next step, --dry-run could be added to systemctl, which in
turn might pave the way for a long requested dry-run feature when
running systemctl start.
When a unit file is invalid, we'd return an error without any details:
$ systemctl --root=/ enable testing@instance.service
Failed to enable: Invalid argument.
Fix things to at least print the offending file name:
$ systemctl enable testing@instance.service
Failed to enable unit: File testing@instance.service: Invalid argument
$ systemctl --root=/ enable testing@instance.service
Failed to enable unit, file testing@instance.service: Invalid argument.
A real fix would be to pass back a proper error message from conf-parser.
But this would require major surgery, since conf-parser functions now
simply print log errors, but we would need to return them over the bus.
So let's just print the file name, to indicate where the error is.
(Incomplete) fix for #4210.
Test case:
[Install]
WantedBy= default.target
Also=foobar-unknown.service
Before:
$ systemctl --root=/ enable testing2@instance.service
Failed to enable: No such file or directory.
After
$ ./systemctl --root=/ enable testing2@instance.service
Failed to enable unit, file foobar-unknown.service: No such file or directory.
With the following test case:
[Install]
WantedBy= default.target
Also=foobar-unknown.service
disabling would fail with:
$ ./systemctl --root=/ disable testing.service
Cannot find unit foobar-unknown.service. # this is level debug
Failed to disable: No such file or directory. # this is the error
After the change we proceed:
$ ./systemctl --root=/ disable testing.service
Cannot find unit foobar-unknown.service.
Removed /etc/systemd/system/default.target.wants/testing.service.
This does not affect specifying a missing unit directly:
$ ./systemctl --root=/ disable nosuch.service
Failed to disable: No such file or directory.
It's a common pattern, so add a helper for it. A macro is necessary
because a function that takes a pointer to a pointer would be type specific,
similarly to cleanup functions. Seems better to use a macro.
https://bugzilla.redhat.com/show_bug.cgi?id=1374371
When root was empty or equal to "/", chroot_symlinks_same was called with
root==NULL, and strjoina returned "", so the code thought both paths are equal
even if they were not. Fix that by always providing a non-null first argument
to strjoina.
When told to enable a template unit, and the DefaultInstance specified in that
unit was masked, we would do this. Such a unit cannot be started or loaded, so
reporting successful enabling is misleading and unexpected.
$ systemctl mask getty@tty1
Created symlink /etc/systemd/system/getty@tty1.service → /dev/null.
$ systemctl --root=/ enable getty@tty1
(unchanged)
Failed to enable unit, unit /etc/systemd/system/getty@tty1.service is masked.
$ systemctl --root=/ enable getty@
(before)
Created symlink /etc/systemd/system/getty.target.wants/getty@tty1.service → /usr/lib/systemd/system/getty@.service.
(now)
Failed to enable unit, unit /etc/systemd/system/getty@tty1.service is masked.
The same error is emitted for enable and preset. And an error is emmited, not a
warning, so the failure to enable DefaultInstance is treated the same as if the
instance was specified on the command line. I think that this makes most sense,
for most template units.
Fixes#2513.
A masked unit is listed in Also=:
$ systemctl cat test1 test2
→# /etc/systemd/system/test1.service
[Unit]
Description=test service 1
[Service]
Type=oneshot
ExecStart=/usr/bin/true
[Install]
WantedBy=multi-user.target
Also=test2.service
Alias=alias1.service
→# /dev/null
$ systemctl --root=/ enable test1
(before)
Created symlink /etc/systemd/system/alias1.service → /etc/systemd/system/test1.service.
Created symlink /etc/systemd/system/multi-user.target.wants/test1.service → /etc/systemd/system/test1.service.
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
instance name specified.
(after)
Created symlink /etc/systemd/system/alias1.service → /etc/systemd/system/test1.service.
Created symlink /etc/systemd/system/multi-user.target.wants/test1.service → /etc/systemd/system/test1.service.
Unit /etc/systemd/system/test2.service is masked, ignoring.
Running preset-all on a system installed from rpms or even created
using make install would remove and recreate a lot of symlinks, changing
relative to absolute symlinks. In general relative symlinks are nicer,
so there is no reason to change them, and those spurious changes were
obscuring more interesting stuff.
$ make install DESTDIR=/var/tmp/inst1
$ systemctl preset-all --root=/var/tmp/inst1
(before)
Removed /var/tmp/inst1/etc/systemd/system/network-online.target.wants/systemd-networkd-wait-online.service.
Created symlink /var/tmp/inst1/etc/systemd/system/ctrl-alt-del.target → /usr/lib/systemd/system/exit.target.
Removed /var/tmp/inst1/etc/systemd/system/multi-user.target.wants/remote-fs.target.
Created symlink /var/tmp/inst1/etc/systemd/system/multi-user.target.wants/remote-fs.target → /usr/lib/systemd/system/remote-fs.target.
Created symlink /var/tmp/inst1/etc/systemd/system/multi-user.target.wants/machines.target → /usr/lib/systemd/system/machines.target.
Created symlink /var/tmp/inst1/etc/systemd/system/sockets.target.wants/systemd-journal-remote.socket → /usr/lib/systemd/system/systemd-journal-remote.socket.
Removed /var/tmp/inst1/etc/systemd/system/sockets.target.wants/systemd-networkd.socket.
Created symlink /var/tmp/inst1/etc/systemd/system/sockets.target.wants/systemd-networkd.socket → /usr/lib/systemd/system/systemd-networkd.socket.
Removed /var/tmp/inst1/etc/systemd/system/getty.target.wants/getty@tty1.service.
Created symlink /var/tmp/inst1/etc/systemd/system/getty.target.wants/getty@tty1.service → /usr/lib/systemd/system/getty@.service.
Created symlink /var/tmp/inst1/etc/systemd/system/multi-user.target.wants/systemd-journal-upload.service → /usr/lib/systemd/system/systemd-journal-upload.service.
Removed /var/tmp/inst1/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service.
Created symlink /var/tmp/inst1/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service → /usr/lib/systemd/system/systemd-timesyncd.service.
Removed /var/tmp/inst1/etc/systemd/system/multi-user.target.wants/systemd-resolved.service.
Created symlink /var/tmp/inst1/etc/systemd/system/multi-user.target.wants/systemd-resolved.service → /usr/lib/systemd/system/systemd-resolved.service.
Removed /var/tmp/inst1/etc/systemd/system/multi-user.target.wants/systemd-networkd.service.
Created symlink /var/tmp/inst1/etc/systemd/system/multi-user.target.wants/systemd-networkd.service → /usr/lib/systemd/system/systemd-networkd.service.
(after)
Removed /var/tmp/inst1/etc/systemd/system/network-online.target.wants/systemd-networkd-wait-online.service.
Created symlink /var/tmp/inst1/etc/systemd/system/ctrl-alt-del.target → /usr/lib/systemd/system/exit.target.
Created symlink /var/tmp/inst1/etc/systemd/system/multi-user.target.wants/machines.target → /usr/lib/systemd/system/machines.target.
Created symlink /var/tmp/inst1/etc/systemd/system/sockets.target.wants/systemd-journal-remote.socket → /usr/lib/systemd/system/systemd-journal-remote.socket.
Created symlink /var/tmp/inst1/etc/systemd/system/multi-user.target.wants/systemd-journal-upload.service → /usr/lib/systemd/system/systemd-journal-upload.service.
Before, when interating over unit files during preset-all, behaviour was the
following:
- if we hit the real unit name first, presets were queried for that name, and
that unit was enabled or disabled accordingly,
- if we hit an alias first (one of the symlinks chaining to the real unit), we
checked the presets using the symlink name, and then proceeded to enable or
disable the real unit.
E.g. for systemd-networkd.service we have the alias dbus-org.freedesktop.network1.service
(/usr/lib/systemd/system/dbus-org.freedesktop.network1.service), but the preset
is only for the systemd-networkd.service name. The service would be enabled or
disabled pseudorandomly depending on the order of iteration.
For "preset", behaviour was analogous: preset on the alias name disabled the
service (following the default disable policy), preset on the "real" name
applied the presets.
With the patch, for "preset" and "preset-all" we silently skip symlinks. This
gives mostly the right behaviour, with the limitation that presets on aliases
are ignored. I think that presets on aliases are not that common (at least my
preset files on Fedora don't exhibit any such usage), and should not be
necessary, since whoever installs the preset can just refer to the real unit
file. It would be possible to overcome this limitation by gathering a list of
names of a unit first, and then checking whether *any* of the names matches the
presets list. That would require a significant redesign of the code, and be
a lot slower (since we would have to fully read all unit directories to preset
one unit) to so I'm not doing that for now.
With this patch, two properties are satisfied:
- preset-all and preset are idempotent, and the second and subsequent invocations
do not produce any changes,
- preset-all and preset for a specific name produce the same state for that unit.
Fixes#3616.
Under NixOS, the config_path /etc/systemd/system is a symlink to
/etc/static/systemd/system. Commands such as `systemctl list-unit-files`
and `systemctl is-enabled` did not work as the symlink was not followed.
This does not affect how symlinks are treated within the config_path
directory.
User expectations are broken when "systemctl enable /some/path/service.service"
behaves differently to "systemctl link ..." followed by "systemctl enable".
From user's POV, "enable" with the full path just combines the two steps into
one.
Fixes#3010.
If for whatever reason the file system is "corrupted", we want
to be resilient and ignore the error, as long as we can load the units
from a different place.
Arch bug https://bugs.archlinux.org/task/49547.
A user had an ntfs symlink (essentially a file) instead of a directory after
restoring from backup. We should just ignore that like we would treat a missing
directory, for general resiliency.
We should treat permission errors similarly. For example an unreadable
/usr/local/lib directory would prevent (user) instances of systemd from
loading any units. It seems better to continue.
That function doesn't draw anything on it's own, just returns a string, which
sometimes is more than one character. Also remove "DRAW_" prefix from character
names, TREE_* and ARROW and BLACK_CIRCLE are unambigous on their own, don't
draw anything, and are always used as an argument to special_glyph().
Rename "DASH" to "MDASH", as there's more than one type of dash.
It's quite a bit shorter and just as readable.
(The full sentence with "pointing to" was added to replace a text that used
"ln -s %s %s". Using the "ln" syntax is indeed unclear, because it's not
obvious which is the source and which is the target, and because symlink(2)
uses the opposite order to ln(1). But with the unicode arrow there should
be no ambiguity.)
Executing 'systemctl enable' on the same unit twice would cause
a warning about a missing [Install] section to be printed. To avoid
this, count all symlinks that "would" be created, and return 1
no matter if we actually created a symlink or skipped creation because
it already exists.
This fixes 'preset-all' with a unit that is a dangling symlink.
$ systemctl --root=/ preset-all
Unit syslog.service is an alias to a unit that is not present, ignoring.
Unit auditd.service is masked, ignoring.
Unit NetworkManager.service is masked, ignoring.
