Zbigniew Jędrzejewski-Szmek 047d37dc3d shared/install: reuse the standard symlink verification subroutine
We save a few lines, but the important thing is that we don't have two
different implementations with slightly different rules used for enablement
and loading. Fixes #22000.

Tested with:
- the report in #22000, it now says:
$ SYSTEMD_LOG_LEVEL=debug systemctl --root=/ enable test.service
Suspicious symlink /etc/systemd/system/test.service→/etc/systemd/system/myown.d/test.service, treating as alias.
unit_file_resolve_symlink: self-alias: /etc/systemd/system/test.service → test.service, ignoring.
running_in_chroot(): Permission denied
Suspicious symlink /etc/systemd/system/test.service→/etc/systemd/system/myown.d/test.service, treating as alias.
unit_file_resolve_symlink: self-alias: /etc/systemd/system/test.service → test.service, ignoring.
Failed to enable unit, refusing to operate on linked unit file test.service

- a symlink to /dev/null:
...
unit_file_resolve_symlink: linked unit file: /etc/systemd/system/test3.service → /dev/null
Failed to enable unit, unit /etc/systemd/system/test3.service is masked.

- the same from the host:
...
unit_file_resolve_symlink: linked unit file: /var/lib/machines/rawhide/etc/systemd/system/test3.service → /var/lib/machines/rawhide/dev/null
Failed to enable unit, unit /var/lib/machines/rawhide/etc/systemd/system/test3.service is masked.

- through the manager:
$ sudo systemctl enable test.service
Failed to enable unit: Refusing to operate on alias name or linked unit file: test.service
$ sudo systemctl enable test3.service
Failed to enable unit: Unit file /etc/systemd/system/test3.service is masked.

As seen in the first example, the warning is repeated. This is because we call
the lookup logic twice: first for sysv-compat, and then again for real. I think
that since this is only for broken setups, and when sysv-compat is enabled, and
in an infrequent manual operation, at debug level, this is OK.
2022-03-29 16:16:02 +02:00
2022-03-06 13:07:20 +09:00
2022-03-23 13:47:15 +01:00
2022-03-20 09:47:33 +01:00
2022-03-11 09:34:04 +00:00
2021-03-30 13:17:58 +02:00
2022-03-09 09:52:41 +00:00
2019-04-12 08:30:31 +02:00
2021-09-30 12:27:06 +02:00
2022-03-23 12:22:53 +09:00
2021-12-14 15:27:25 +09:00
2022-03-23 12:29:20 +01:00

Systemd

System and Service Manager

Count of open issues over time Count of open pull requests over time Semaphore CI 2.0 Build Status
Coverity Scan Status
OSS-Fuzz Status
CIFuzz
CII Best Practices
Language Grade: C/C++
CentOS CI - CentOS 8
CentOS CI - Arch
CentOS CI - Arch (sanitizers)
Fossies codespell report
Coverage Status
Packaging status

Details

Most documentation is available on systemd's web site.

Assorted, older, general information about systemd can be found in the systemd Wiki.

Information about build requirements is provided in the README file.

Consult our NEWS file for information about what's new in the most recent systemd versions.

Please see the Code Map for information about this repository's layout and content.

Please see the Hacking guide for information on how to hack on systemd and test your modifications.

Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.

When preparing patches for systemd, please follow our Coding Style Guidelines.

If you are looking for support, please contact our mailing list or join our IRC channel.

Stable branches with backported patches are available in the stable repo.

S
Description
systemd patched fork
Readme
409 MiB
Languages
C 88.5%
Shell 5.7%
Python 4.6%
Meson 1.1%