shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2024-12-22 17:35:35 +03:00
Code
398d5a368c
systemd/test/test-systemctl-enable.sh

727 lines
32 KiB
Bash
Raw Normal View History

test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
#!/usr/bin/env bash
# SPDX-License-Identifier: LGPL-2.1-or-later
set -ex
# Silence warning from running_in_chroot_or_offline()
Add $SYSTEMD_IN_CHROOT to override chroot detection When running unprivileged, checking /proc/1/root doesn't work because it requires privileges. Instead, let's add an environment variable so the process that chroot's can tell (systemd) subprocesses whether they're running in a chroot or not. (cherry picked from commit 2701c2f67de592fe2565b084cfaec1667767dbaf)
2024-08-14 13:43:05 +03:00
export SYSTEMD_IN_CHROOT=0
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
systemctl=${1:-systemctl}
test-systemctl-enable: also use freshly-built systemd-id128 Tests were failing on centos7 because systemd-id128 is not in path.
2022-03-28 21:03:37 +03:00
systemd_id128=${2:-systemd-id128}
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
unset root
cleanup() {
[ -n "$root" ] && rm -rf "$root"
}
trap cleanup exit
root=$(mktemp -d --tmpdir systemctl-test.XXXXXX)
islink() {
test -h "$1" || return 1
test "$(readlink "$1")" = "$2" || return 2
}
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------enable nonexistent--------------------------------------'
test-systemctl-enable: use magic syntax to allow inverted tests Inspired by 7910ec3bcde2ee0086b3e49f8aaa2a9f13f58d97. '! true' passes, because it's a conditional expression. But '( ! true )' fails, because '( … )' creates a subshell, i.e. a separate program, and '! true' becomes the return value of that program, and the whole thing apparently is not a conditional expression for the outer shell. This is shorter, so let's just do this.
2022-03-25 17:56:16 +03:00
( ! "$systemctl" --root="$root" enable test1.service )
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------basic enablement----------------------------------------'
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
mkdir -p "$root/etc/systemd/system"
cat >"$root/etc/systemd/system/test1.service" <<EOF
[Install]
WantedBy=default.target
RequiredBy=special.target
EOF
"$systemctl" --root="$root" enable test1.service
test -h "$root/etc/systemd/system/default.target.wants/test1.service"
test -h "$root/etc/systemd/system/special.target.requires/test1.service"
"$systemctl" --root="$root" reenable test1.service
test -h "$root/etc/systemd/system/default.target.wants/test1.service"
test -h "$root/etc/systemd/system/special.target.requires/test1.service"
"$systemctl" --root="$root" disable test1.service
shared/install: when creating symlinks, accept different but equivalent symlinks We would only accept "identical" links, but having e.g. a symlink /usr/lib/systemd/system/foo-alias.service → /usr/lib/systemd/system/foo.service when we're trying to create /usr/lib/systemd/system/foo-alias.service → ./foo.service is OK. This fixes an issue found in ubuntuautopkg package installation, where we'd fail when enabling systemd-resolved.service, because the existing alias was absolute, and (with the recent patches) we were trying to create a relative one. A test is added. (For .wants/.requires symlinks we were already doing OK. A test is also added, to verify.)
2022-03-25 17:43:27 +03:00
test ! -h "$root/etc/systemd/system/default.target.wants/test1.service"
test ! -h "$root/etc/systemd/system/special.target.requires/test1.service"
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------enable when link already exists-------------------------'
shared/install: when creating symlinks, accept different but equivalent symlinks We would only accept "identical" links, but having e.g. a symlink /usr/lib/systemd/system/foo-alias.service → /usr/lib/systemd/system/foo.service when we're trying to create /usr/lib/systemd/system/foo-alias.service → ./foo.service is OK. This fixes an issue found in ubuntuautopkg package installation, where we'd fail when enabling systemd-resolved.service, because the existing alias was absolute, and (with the recent patches) we were trying to create a relative one. A test is added. (For .wants/.requires symlinks we were already doing OK. A test is also added, to verify.)
2022-03-25 17:43:27 +03:00
# We don't read the symlink target, so it's OK for the symlink to point
# to something else. We should just silently accept this.
mkdir -p "$root/etc/systemd/system/default.target.wants"
mkdir -p "$root/etc/systemd/system/special.target.requires"
ln -s /usr/lib/systemd/system/test1.service "$root/etc/systemd/system/default.target.wants/test1.service"
ln -s /usr/lib/systemd/system/test1.service "$root/etc/systemd/system/special.target.requires/test1.service"
"$systemctl" --root="$root" enable test1.service
test -h "$root/etc/systemd/system/default.target.wants/test1.service"
test -h "$root/etc/systemd/system/special.target.requires/test1.service"
"$systemctl" --root="$root" reenable test1.service
test -h "$root/etc/systemd/system/default.target.wants/test1.service"
test -h "$root/etc/systemd/system/special.target.requires/test1.service"
"$systemctl" --root="$root" disable test1.service
test ! -h "$root/etc/systemd/system/default.target.wants/test1.service"
test ! -h "$root/etc/systemd/system/special.target.requires/test1.service"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------suffix guessing-----------------------------------------'
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
"$systemctl" --root="$root" enable test1
test -h "$root/etc/systemd/system/default.target.wants/test1.service"
test -h "$root/etc/systemd/system/special.target.requires/test1.service"
"$systemctl" --root="$root" reenable test1
test -h "$root/etc/systemd/system/default.target.wants/test1.service"
test -h "$root/etc/systemd/system/special.target.requires/test1.service"
"$systemctl" --root="$root" disable test1
test ! -e "$root/etc/systemd/system/default.target.wants/test1.service"
test ! -e "$root/etc/systemd/system/special.target.requires/test1.service"
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------aliases-------------------------------------------------'
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
cat >>"$root/etc/systemd/system/test1.service" <<EOF
Alias=test1-goodalias.service
Alias=test1@badalias.service
Alias=test1-badalias.target
Alias=test1-badalias.socket
shared/install: return failure when enablement fails, but process as much as possible So far we'd issue a warning (before this series, just in the logs on the server side, and before this commit, on stderr on the caller's side), but return success. It seems that successfull return was introduced by mistake in aa0f357fd833feecbea6c3e9be80b643e433bced (my fault :( ), which was supposed to be a refactoring without a functional change. I think it's better to fail, because if enablement fails, the user will most likely want to diagnose the issue. Note that we still do partial enablement, as far as that is possible. So if e.g. we have [Install] Alias=foo.service foobar, we'll create the symlink 'foo.service', but not 'foobar', since that's not a valid unit name. We'll print info about the action taken, and about 'foobar' being invalid, and return failure.
2022-03-10 17:47:12 +03:00
# we have a series of good, bad, and then good again
Alias=test1-goodalias2.service
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
EOF
test-systemctl-enable: use magic syntax to allow inverted tests Inspired by 7910ec3bcde2ee0086b3e49f8aaa2a9f13f58d97. '! true' passes, because it's a conditional expression. But '( ! true )' fails, because '( … )' creates a subshell, i.e. a separate program, and '! true' becomes the return value of that program, and the whole thing apparently is not a conditional expression for the outer shell. This is shorter, so let's just do this.
2022-03-25 17:56:16 +03:00
( ! "$systemctl" --root="$root" enable test1 )
shared/install: return failure when enablement fails, but process as much as possible So far we'd issue a warning (before this series, just in the logs on the server side, and before this commit, on stderr on the caller's side), but return success. It seems that successfull return was introduced by mistake in aa0f357fd833feecbea6c3e9be80b643e433bced (my fault :( ), which was supposed to be a refactoring without a functional change. I think it's better to fail, because if enablement fails, the user will most likely want to diagnose the issue. Note that we still do partial enablement, as far as that is possible. So if e.g. we have [Install] Alias=foo.service foobar, we'll create the symlink 'foo.service', but not 'foobar', since that's not a valid unit name. We'll print info about the action taken, and about 'foobar' being invalid, and return failure.
2022-03-10 17:47:12 +03:00
test -h "$root/etc/systemd/system/default.target.wants/test1.service"
test -h "$root/etc/systemd/system/special.target.requires/test1.service"
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
test ! -e "$root/etc/systemd/system/test1-goodalias.service"
shared/install: return failure when enablement fails, but process as much as possible So far we'd issue a warning (before this series, just in the logs on the server side, and before this commit, on stderr on the caller's side), but return success. It seems that successfull return was introduced by mistake in aa0f357fd833feecbea6c3e9be80b643e433bced (my fault :( ), which was supposed to be a refactoring without a functional change. I think it's better to fail, because if enablement fails, the user will most likely want to diagnose the issue. Note that we still do partial enablement, as far as that is possible. So if e.g. we have [Install] Alias=foo.service foobar, we'll create the symlink 'foo.service', but not 'foobar', since that's not a valid unit name. We'll print info about the action taken, and about 'foobar' being invalid, and return failure.
2022-03-10 17:47:12 +03:00
test -h "$root/etc/systemd/system/test1-goodalias.service"
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
test ! -e "$root/etc/systemd/system/test1@badalias.service"
test ! -e "$root/etc/systemd/system/test1-badalias.target"
test ! -e "$root/etc/systemd/system/test1-badalias.socket"
shared/install: return failure when enablement fails, but process as much as possible So far we'd issue a warning (before this series, just in the logs on the server side, and before this commit, on stderr on the caller's side), but return success. It seems that successfull return was introduced by mistake in aa0f357fd833feecbea6c3e9be80b643e433bced (my fault :( ), which was supposed to be a refactoring without a functional change. I think it's better to fail, because if enablement fails, the user will most likely want to diagnose the issue. Note that we still do partial enablement, as far as that is possible. So if e.g. we have [Install] Alias=foo.service foobar, we'll create the symlink 'foo.service', but not 'foobar', since that's not a valid unit name. We'll print info about the action taken, and about 'foobar' being invalid, and return failure.
2022-03-10 17:47:12 +03:00
test -h "$root/etc/systemd/system/test1-goodalias2.service"
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------aliases in reenable-------------------------------------'
test-systemctl-enable: use magic syntax to allow inverted tests Inspired by 7910ec3bcde2ee0086b3e49f8aaa2a9f13f58d97. '! true' passes, because it's a conditional expression. But '( ! true )' fails, because '( … )' creates a subshell, i.e. a separate program, and '! true' becomes the return value of that program, and the whole thing apparently is not a conditional expression for the outer shell. This is shorter, so let's just do this.
2022-03-25 17:56:16 +03:00
( ! "$systemctl" --root="$root" reenable test1 )
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
test -h "$root/etc/systemd/system/default.target.wants/test1.service"
test ! -e "$root/etc/systemd/system/test1-goodalias.service"
test -h "$root/etc/systemd/system/test1-goodalias.service"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
test ! -e "$root/etc/systemd/system/test1@badalias.service"
test ! -e "$root/etc/systemd/system/test1-badalias.target"
test ! -e "$root/etc/systemd/system/test1-badalias.socket"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
"$systemctl" --root="$root" disable test1
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
test ! -e "$root/etc/systemd/system/default.target.wants/test1.service"
test ! -e "$root/etc/systemd/system/special.target.requires/test1.service"
test ! -e "$root/etc/systemd/system/test1-goodalias.service"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------aliases when link already exists------------------------'
shared/install: when creating symlinks, accept different but equivalent symlinks We would only accept "identical" links, but having e.g. a symlink /usr/lib/systemd/system/foo-alias.service → /usr/lib/systemd/system/foo.service when we're trying to create /usr/lib/systemd/system/foo-alias.service → ./foo.service is OK. This fixes an issue found in ubuntuautopkg package installation, where we'd fail when enabling systemd-resolved.service, because the existing alias was absolute, and (with the recent patches) we were trying to create a relative one. A test is added. (For .wants/.requires symlinks we were already doing OK. A test is also added, to verify.)
2022-03-25 17:43:27 +03:00
cat >"$root/etc/systemd/system/test1a.service" <<EOF
[Install]
Alias=test1a-alias.service
EOF
ln -s /usr/lib/systemd/system/test1a.service "$root/etc/systemd/system/test1a-alias.service"
"$systemctl" --root="$root" enable test1a.service
test -h "$root/etc/systemd/system/test1a-alias.service"
"$systemctl" --root="$root" disable test1a.service
test ! -h "$root/etc/systemd/system/test1a-alias.service"
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------also units----------------------------------------------'
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
cat >"$root/etc/systemd/system/test2.socket" <<EOF
[Install]
WantedBy=sockets.target
Also=test2.service
EOF
cat >"$root/etc/systemd/system/test2.service" <<EOF
[Install]
WantedBy=default.target
Also=test2.socket
EOF
"$systemctl" --root="$root" reenable test2.service
test -h "$root/etc/systemd/system/default.target.wants/test2.service"
test -h "$root/etc/systemd/system/sockets.target.wants/test2.socket"
"$systemctl" --root="$root" reenable test2.socket
test -h "$root/etc/systemd/system/default.target.wants/test2.service"
test -h "$root/etc/systemd/system/sockets.target.wants/test2.socket"
"$systemctl" --root="$root" disable test2.socket
test ! -e "$root/etc/systemd/system/default.target.wants/test2.service"
test ! -e "$root/etc/systemd/system/sockets.target.wants/test2.socket"
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------link----------------------------------------------------'
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
# File doesn't exist yet
test ! -e "$root/link1.path"
test-systemctl-enable: use magic syntax to allow inverted tests Inspired by 7910ec3bcde2ee0086b3e49f8aaa2a9f13f58d97. '! true' passes, because it's a conditional expression. But '( ! true )' fails, because '( … )' creates a subshell, i.e. a separate program, and '! true' becomes the return value of that program, and the whole thing apparently is not a conditional expression for the outer shell. This is shorter, so let's just do this.
2022-03-25 17:56:16 +03:00
( ! "$systemctl" --root="$root" link '/link1.path' )
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test ! -e "$root/etc/systemd/system/link1.path"
cat >"$root/link1.path" <<EOF
[Install]
WantedBy=paths.target
EOF
"$systemctl" --root="$root" link '/link1.path'
islink "$root/etc/systemd/system/link1.path" "/link1.path"
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------link already linked same path---------------------------'
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
SYSTEMD_LOG_LEVEL=debug "$systemctl" --root="$root" link '/link1.path' # this passes
islink "$root/etc/systemd/system/link1.path" "/link1.path"
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------link already linked different path----------------------'
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
mkdir "$root/subdir"
cp "$root/link1.path" "$root/subdir/"
test-systemctl-enable: use magic syntax to allow inverted tests Inspired by 7910ec3bcde2ee0086b3e49f8aaa2a9f13f58d97. '! true' passes, because it's a conditional expression. But '( ! true )' fails, because '( … )' creates a subshell, i.e. a separate program, and '! true' becomes the return value of that program, and the whole thing apparently is not a conditional expression for the outer shell. This is shorter, so let's just do this.
2022-03-25 17:56:16 +03:00
( ! "$systemctl" --root="$root" link '/subdir/link1.path' )
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
islink "$root/etc/systemd/system/link1.path" "/link1.path"
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------link bad suffix-----------------------------------------'
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
cp "$root/link1.path" "$root/subdir/link1.suffix"
test-systemctl-enable: use magic syntax to allow inverted tests Inspired by 7910ec3bcde2ee0086b3e49f8aaa2a9f13f58d97. '! true' passes, because it's a conditional expression. But '( ! true )' fails, because '( … )' creates a subshell, i.e. a separate program, and '! true' becomes the return value of that program, and the whole thing apparently is not a conditional expression for the outer shell. This is shorter, so let's just do this.
2022-03-25 17:56:16 +03:00
( ! "$systemctl" --root="$root" link '/subdir/link1.suffix' )
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test ! -e "$root/etc/systemd/system/link1.suffix"
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------unlink by unit name-------------------------------------'
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
"$systemctl" --root="$root" disable 'link1.path'
test ! -e "$root/etc/systemd/system/link1.path"
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------unlink by path------------------------------------------'
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
"$systemctl" --root="$root" link '/link1.path'
test -h "$root/etc/systemd/system/link1.path"
"$systemctl" --root="$root" disable '/link1.path'
test ! -e "$root/etc/systemd/system/link1.path"
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------unlink by wrong path------------------------------------'
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
"$systemctl" --root="$root" link '/link1.path'
test -h "$root/etc/systemd/system/link1.path"
"$systemctl" --root="$root" disable '/subdir/link1.path' # we only care about the name
test ! -e "$root/etc/systemd/system/link1.path"
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------link and enable-----------------------------------------'
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
"$systemctl" --root="$root" enable '/link1.path'
islink "$root/etc/systemd/system/link1.path" "/link1.path"
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
islink "$root/etc/systemd/system/paths.target.wants/link1.path" "/link1.path"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------enable already linked same path-------------------------'
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
"$systemctl" --root="$root" enable '/link1.path'
islink "$root/etc/systemd/system/link1.path" "/link1.path"
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
islink "$root/etc/systemd/system/paths.target.wants/link1.path" "/link1.path"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------enable already linked different path--------------------'
test-systemctl-enable: use magic syntax to allow inverted tests Inspired by 7910ec3bcde2ee0086b3e49f8aaa2a9f13f58d97. '! true' passes, because it's a conditional expression. But '( ! true )' fails, because '( … )' creates a subshell, i.e. a separate program, and '! true' becomes the return value of that program, and the whole thing apparently is not a conditional expression for the outer shell. This is shorter, so let's just do this.
2022-03-25 17:56:16 +03:00
( ! "$systemctl" --root="$root" enable '/subdir/link1.path' )
install: when linking a file, create the link first or abort We'd create aliases and other symlinks first, and only then try to create the main link. Since that can fail, let's do things in opposite order, and abort immediately if we can't link the file itself.
2022-03-11 16:27:46 +03:00
islink "$root/etc/systemd/system/link1.path" "/link1.path"
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
islink "$root/etc/systemd/system/paths.target.wants/link1.path" "/link1.path"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------enable bad suffix---------------------------------------'
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
cp "$root/link1.path" "$root/subdir/link1.suffix"
test-systemctl-enable: use magic syntax to allow inverted tests Inspired by 7910ec3bcde2ee0086b3e49f8aaa2a9f13f58d97. '! true' passes, because it's a conditional expression. But '( ! true )' fails, because '( … )' creates a subshell, i.e. a separate program, and '! true' becomes the return value of that program, and the whole thing apparently is not a conditional expression for the outer shell. This is shorter, so let's just do this.
2022-03-25 17:56:16 +03:00
( ! "$systemctl" --root="$root" enable '/subdir/link1.suffix' )
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test ! -e "$root/etc/systemd/system/link1.suffix"
test ! -e "$root/etc/systemd/system/paths.target.wants/link1.suffix"
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------disable by unit name------------------------------------'
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
"$systemctl" --root="$root" disable 'link1.path'
test ! -e "$root/etc/systemd/system/link1.path"
test ! -e "$root/etc/systemd/system/paths.target.wants/link1.path"
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------disable by path-----------------------------------------'
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
"$systemctl" --root="$root" enable '/link1.path'
test -h "$root/etc/systemd/system/link1.path"
test -h "$root/etc/systemd/system/paths.target.wants/link1.path"
"$systemctl" --root="$root" disable '/link1.path'
test ! -e "$root/etc/systemd/system/link1.path"
test ! -e "$root/etc/systemd/system/paths.target.wants/link1.path"
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------link and enable-----------------------------------------'
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
"$systemctl" --root="$root" link '/link1.path'
islink "$root/etc/systemd/system/link1.path" "/link1.path"
test ! -h "$root/etc/systemd/system/paths.target.wants/link1.path"
"$systemctl" --root="$root" enable 'link1.path'
islink "$root/etc/systemd/system/link1.path" "/link1.path"
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
islink "$root/etc/systemd/system/paths.target.wants/link1.path" "/link1.path"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
shared/install: fix reenable on linked unit files
2022-03-15 11:44:39 +03:00
"$systemctl" --root="$root" reenable 'link1.path'
islink "$root/etc/systemd/system/link1.path" "/link1.path"
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
islink "$root/etc/systemd/system/paths.target.wants/link1.path" "/link1.path"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------link instance and enable--------------------------------'
install: don't translate unit instances to paths when reenabling them For unit instances install_info_discover() returns path to the template, which then generates confusing errors when passed to do_unit_file_enable(): ~# build/systemctl --root=/tmp/systemctl-test.N9ysbz reenable templ1@two.service Unit name: templ1@two.service; p: /etc/systemd/system/templ1@.service Removed "/tmp/systemctl-test.N9ysbz/etc/systemd/system/services.target.wants/templ1@two.service". Failed to reenable templ1@.service, destination unit services.target is a non-template unit. This can also be seen with a different reproducer using getty@.service and a simple bind mount to / - there's no error this time, but it tries to create a symlink for the default instance (from DefaultInstance=tty1), which is also incorrect: ~# SYSTEMD_LOG_LEVEL=debug systemctl --root /mnt/bindroot/ reenable getty@test.service Symlink /mnt/bindroot/etc/systemd/system/getty.target.wants/getty@tty1.service → /usr/lib/systemd/system/getty@.service already exists Follow-up to: 29a7c59abbe Resolves: #24740
2023-12-06 18:24:21 +03:00
cat >"$root/link-instance@.service" <<EOF
[Service]
ExecStart=true
[Install]
WantedBy=services.target
EOF
"$systemctl" --root="$root" link '/link-instance@.service'
islink "$root/etc/systemd/system/link-instance@.service" "/link-instance@.service"
"$systemctl" --root="$root" enable 'link-instance@first.service'
islink "$root/etc/systemd/system/link-instance@first.service" "/link-instance@.service"
islink "$root/etc/systemd/system/services.target.wants/link-instance@first.service" "/link-instance@.service"
SYSTEMD_LOG_LEVEL=debug "$systemctl" --root="$root" reenable 'link-instance@first.service'
islink "$root/etc/systemd/system/link-instance@first.service" "/link-instance@.service"
islink "$root/etc/systemd/system/services.target.wants/link-instance@first.service" "/link-instance@.service"
"$systemctl" --root="$root" disable 'link-instance@first.service'
test ! -h "$root/etc/systemd/system/link-instance@first.service"
test ! -h "$root/etc/systemd/system/services.target.wants/link-instance@first.service"
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------manual link---------------------------------------------'
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
cat >"$root/link3.suffix" <<EOF
[Install]
WantedBy=services.target
EOF
shared/install: fix handling of a linked unit file When we have a symlink that goes outside of our search path, we should just ignore the target file name. But we were verifying it, and rejecting in the case where a symlink was created manually.
2022-03-17 18:02:10 +03:00
# We wouldn't create such a link ourselves, but it should accept it when present.
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
ln -s "/link3.suffix" "$root/etc/systemd/system/link3.service"
shared/install: fix handling of a linked unit file When we have a symlink that goes outside of our search path, we should just ignore the target file name. But we were verifying it, and rejecting in the case where a symlink was created manually.
2022-03-17 18:02:10 +03:00
SYSTEMD_LOG_LEVEL=debug SYSTEMD_LOG_LOCATION=1 "$systemctl" --root="$root" enable 'link3.service'
islink "$root/etc/systemd/system/link3.service" "/link3.suffix"
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
islink "$root/etc/systemd/system/services.target.wants/link3.service" "/link3.suffix"
shared/install: fix handling of a linked unit file When we have a symlink that goes outside of our search path, we should just ignore the target file name. But we were verifying it, and rejecting in the case where a symlink was created manually.
2022-03-17 18:02:10 +03:00
SYSTEMD_LOG_LEVEL=debug SYSTEMD_LOG_LOCATION=1 "$systemctl" --root="$root" disable 'link3.service'
test ! -h "$root/etc/systemd/system/link3.service"
test ! -h "$root/etc/systemd/system/services.target.wants/link3.service"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------enable on masked----------------------------------------'
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
ln -s "/dev/null" "$root/etc/systemd/system/masked.service"
test-systemctl-enable: use magic syntax to allow inverted tests Inspired by 7910ec3bcde2ee0086b3e49f8aaa2a9f13f58d97. '! true' passes, because it's a conditional expression. But '( ! true )' fails, because '( … )' creates a subshell, i.e. a separate program, and '! true' becomes the return value of that program, and the whole thing apparently is not a conditional expression for the outer shell. This is shorter, so let's just do this.
2022-03-25 17:56:16 +03:00
( ! "$systemctl" --root="$root" enable 'masked.service' )
( ! "$systemctl" --root="$root" enable '/etc/systemd/system/masked.service' )
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------enable on masked alias----------------------------------'
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test -h "$root/etc/systemd/system/masked.service"
ln -s "masked.service" "$root/etc/systemd/system/masked-alias.service"
test-systemctl-enable: use magic syntax to allow inverted tests Inspired by 7910ec3bcde2ee0086b3e49f8aaa2a9f13f58d97. '! true' passes, because it's a conditional expression. But '( ! true )' fails, because '( … )' creates a subshell, i.e. a separate program, and '! true' becomes the return value of that program, and the whole thing apparently is not a conditional expression for the outer shell. This is shorter, so let's just do this.
2022-03-25 17:56:16 +03:00
( ! "$systemctl" --root="$root" enable 'masked-alias.service' )
( ! "$systemctl" --root="$root" enable '/etc/systemd/system/masked-alias.service' )
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------issue 22000: link in subdirectory-----------------------'
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
mkdir -p "$root/etc/systemd/system/myown.d"
cat >"$root/etc/systemd/system/link5-also.service" <<EOF
[Install]
WantedBy=services.target
Also=link5.service
EOF
cat >"$root/etc/systemd/system/myown.d/link5.service" <<EOF
[Install]
WantedBy=services.target
Also=link5-also.service
EOF
test-systemctl-enable: use magic syntax to allow inverted tests Inspired by 7910ec3bcde2ee0086b3e49f8aaa2a9f13f58d97. '! true' passes, because it's a conditional expression. But '( ! true )' fails, because '( … )' creates a subshell, i.e. a separate program, and '! true' becomes the return value of that program, and the whole thing apparently is not a conditional expression for the outer shell. This is shorter, so let's just do this.
2022-03-25 17:56:16 +03:00
( ! "$systemctl" --root="$root" enable 'link5.service' )
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test ! -h "$root/etc/systemd/system/services.target.wants/link5.service"
test ! -h "$root/etc/systemd/system/services.target.wants/link5-also.service"
"$systemctl" --root="$root" enable 'link5-also.service'
test ! -h "$root/etc/systemd/system/services.target.wants/link5.service"
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
islink "$root/etc/systemd/system/services.target.wants/link5-also.service" "/etc/systemd/system/link5-also.service"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------template enablement-------------------------------------'
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
cat >"$root/etc/systemd/system/templ1@.service" <<EOF
[Install]
WantedBy=services.target
EOF
# No instance here — this can't succeed.
test-systemctl-enable: use magic syntax to allow inverted tests Inspired by 7910ec3bcde2ee0086b3e49f8aaa2a9f13f58d97. '! true' passes, because it's a conditional expression. But '( ! true )' fails, because '( … )' creates a subshell, i.e. a separate program, and '! true' becomes the return value of that program, and the whole thing apparently is not a conditional expression for the outer shell. This is shorter, so let's just do this.
2022-03-25 17:56:16 +03:00
( ! "$systemctl" --root="$root" enable 'templ1@.service' )
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test ! -h "$root/etc/systemd/system/services.target.wants/templ1@.service"
"$systemctl" --root="$root" enable 'templ1@one.service'
test ! -h "$root/etc/systemd/system/services.target.wants/templ1@.service"
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
islink "$root/etc/systemd/system/services.target.wants/templ1@one.service" "/etc/systemd/system/templ1@.service"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
"$systemctl" --root="$root" enable 'templ1@two.service'
test ! -h "$root/etc/systemd/system/services.target.wants/templ1@.service"
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
islink "$root/etc/systemd/system/services.target.wants/templ1@one.service" "/etc/systemd/system/templ1@.service"
islink "$root/etc/systemd/system/services.target.wants/templ1@two.service" "/etc/systemd/system/templ1@.service"
install: don't translate unit instances to paths when reenabling them For unit instances install_info_discover() returns path to the template, which then generates confusing errors when passed to do_unit_file_enable(): ~# build/systemctl --root=/tmp/systemctl-test.N9ysbz reenable templ1@two.service Unit name: templ1@two.service; p: /etc/systemd/system/templ1@.service Removed "/tmp/systemctl-test.N9ysbz/etc/systemd/system/services.target.wants/templ1@two.service". Failed to reenable templ1@.service, destination unit services.target is a non-template unit. This can also be seen with a different reproducer using getty@.service and a simple bind mount to / - there's no error this time, but it tries to create a symlink for the default instance (from DefaultInstance=tty1), which is also incorrect: ~# SYSTEMD_LOG_LEVEL=debug systemctl --root /mnt/bindroot/ reenable getty@test.service Symlink /mnt/bindroot/etc/systemd/system/getty.target.wants/getty@tty1.service → /usr/lib/systemd/system/getty@.service already exists Follow-up to: 29a7c59abbe Resolves: #24740
2023-12-06 18:24:21 +03:00
"$systemctl" --root="$root" reenable 'templ1@two.service'
test ! -h "$root/etc/systemd/system/services.target.wants/templ1@.service"
islink "$root/etc/systemd/system/services.target.wants/templ1@one.service" "/etc/systemd/system/templ1@.service"
islink "$root/etc/systemd/system/services.target.wants/templ1@two.service" "/etc/systemd/system/templ1@.service"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
"$systemctl" --root="$root" disable 'templ1@one.service'
test ! -h "$root/etc/systemd/system/services.target.wants/templ1@.service"
test ! -h "$root/etc/systemd/system/services.target.wants/templ1@one.service"
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
islink "$root/etc/systemd/system/services.target.wants/templ1@two.service" "/etc/systemd/system/templ1@.service"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
"$systemctl" --root="$root" disable 'templ1@two.service'
test ! -h "$root/etc/systemd/system/services.target.wants/templ1@.service"
test ! -h "$root/etc/systemd/system/services.target.wants/templ1@one.service"
test ! -h "$root/etc/systemd/system/services.target.wants/templ1@two.service"
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------template enablement w/ default instance-----------------'
test-systemctl-enable: extend the test for repeated WantedBy/RequiredBy I was considering deduplicating the list of target units in WantedBy/RequiredBy. But to do this meaningfully, we'd need to do alias expansion first, i.e. after the initial parsing is done. This seems to be more trouble than it would be worth. Instead, I added tests that we're doing the right thing and creating symlinks as expected. For duplicate links, we create the link, and on the second time we see that the link is already there, so the output is correct.
2022-03-15 12:13:18 +03:00
cat >"$root/etc/systemd/system/templ1@.service" <<EOF
[Install]
# check enablement with
WantedBy=services.target services.target
RequiredBy=other@templ1.target other@%p.target
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
DefaultInstance=333
EOF
"$systemctl" --root="$root" enable 'templ1@.service'
test ! -h "$root/etc/systemd/system/services.target.wants/templ1@.service"
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
islink "$root/etc/systemd/system/services.target.wants/templ1@333.service" "/etc/systemd/system/templ1@.service"
islink "$root/etc/systemd/system/other@templ1.target.requires/templ1@333.service" "/etc/systemd/system/templ1@.service"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
"$systemctl" --root="$root" enable 'templ1@one.service'
test ! -h "$root/etc/systemd/system/services.target.wants/templ1@.service"
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
islink "$root/etc/systemd/system/services.target.wants/templ1@333.service" "/etc/systemd/system/templ1@.service"
islink "$root/etc/systemd/system/other@templ1.target.requires/templ1@333.service" "/etc/systemd/system/templ1@.service"
islink "$root/etc/systemd/system/services.target.wants/templ1@one.service" "/etc/systemd/system/templ1@.service"
islink "$root/etc/systemd/system/other@templ1.target.requires/templ1@one.service" "/etc/systemd/system/templ1@.service"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
"$systemctl" --root="$root" enable 'templ1@two.service'
test ! -h "$root/etc/systemd/system/services.target.wants/templ1@.service"
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
islink "$root/etc/systemd/system/services.target.wants/templ1@333.service" "/etc/systemd/system/templ1@.service"
islink "$root/etc/systemd/system/other@templ1.target.requires/templ1@333.service" "/etc/systemd/system/templ1@.service"
islink "$root/etc/systemd/system/services.target.wants/templ1@one.service" "/etc/systemd/system/templ1@.service"
islink "$root/etc/systemd/system/other@templ1.target.requires/templ1@one.service" "/etc/systemd/system/templ1@.service"
islink "$root/etc/systemd/system/services.target.wants/templ1@two.service" "/etc/systemd/system/templ1@.service"
islink "$root/etc/systemd/system/other@templ1.target.requires/templ1@two.service" "/etc/systemd/system/templ1@.service"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
"$systemctl" --root="$root" disable 'templ1@one.service'
test ! -h "$root/etc/systemd/system/services.target.wants/templ1@.service"
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
islink "$root/etc/systemd/system/services.target.wants/templ1@333.service" "/etc/systemd/system/templ1@.service"
islink "$root/etc/systemd/system/other@templ1.target.requires/templ1@333.service" "/etc/systemd/system/templ1@.service"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test ! -h "$root/etc/systemd/system/services.target.wants/templ1@one.service"
test-systemctl-enable: extend the test for repeated WantedBy/RequiredBy I was considering deduplicating the list of target units in WantedBy/RequiredBy. But to do this meaningfully, we'd need to do alias expansion first, i.e. after the initial parsing is done. This seems to be more trouble than it would be worth. Instead, I added tests that we're doing the right thing and creating symlinks as expected. For duplicate links, we create the link, and on the second time we see that the link is already there, so the output is correct.
2022-03-15 12:13:18 +03:00
test ! -h "$root/etc/systemd/system/other@templ1.target.requires/templ1@one.service"
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
islink "$root/etc/systemd/system/services.target.wants/templ1@two.service" "/etc/systemd/system/templ1@.service"
islink "$root/etc/systemd/system/other@templ1.target.requires/templ1@two.service" "/etc/systemd/system/templ1@.service"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test-systemctl-enable: extend the test for repeated WantedBy/RequiredBy I was considering deduplicating the list of target units in WantedBy/RequiredBy. But to do this meaningfully, we'd need to do alias expansion first, i.e. after the initial parsing is done. This seems to be more trouble than it would be worth. Instead, I added tests that we're doing the right thing and creating symlinks as expected. For duplicate links, we create the link, and on the second time we see that the link is already there, so the output is correct.
2022-03-15 12:13:18 +03:00
# disable remaining links here
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
"$systemctl" --root="$root" disable 'templ1@.service'
test ! -h "$root/etc/systemd/system/services.target.wants/templ1@.service"
test ! -h "$root/etc/systemd/system/services.target.wants/templ1@333.service"
test-systemctl-enable: extend the test for repeated WantedBy/RequiredBy I was considering deduplicating the list of target units in WantedBy/RequiredBy. But to do this meaningfully, we'd need to do alias expansion first, i.e. after the initial parsing is done. This seems to be more trouble than it would be worth. Instead, I added tests that we're doing the right thing and creating symlinks as expected. For duplicate links, we create the link, and on the second time we see that the link is already there, so the output is correct.
2022-03-15 12:13:18 +03:00
test ! -h "$root/etc/systemd/system/other@templ1.target.requires/templ1@333.service"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test ! -h "$root/etc/systemd/system/services.target.wants/templ1@one.service"
test-systemctl-enable: extend the test for repeated WantedBy/RequiredBy I was considering deduplicating the list of target units in WantedBy/RequiredBy. But to do this meaningfully, we'd need to do alias expansion first, i.e. after the initial parsing is done. This seems to be more trouble than it would be worth. Instead, I added tests that we're doing the right thing and creating symlinks as expected. For duplicate links, we create the link, and on the second time we see that the link is already there, so the output is correct.
2022-03-15 12:13:18 +03:00
test ! -h "$root/etc/systemd/system/other@templ1.target.requires/templ1@one.service"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test ! -h "$root/etc/systemd/system/services.target.wants/templ1@two.service"
test-systemctl-enable: extend the test for repeated WantedBy/RequiredBy I was considering deduplicating the list of target units in WantedBy/RequiredBy. But to do this meaningfully, we'd need to do alias expansion first, i.e. after the initial parsing is done. This seems to be more trouble than it would be worth. Instead, I added tests that we're doing the right thing and creating symlinks as expected. For duplicate links, we create the link, and on the second time we see that the link is already there, so the output is correct.
2022-03-15 12:13:18 +03:00
test ! -h "$root/etc/systemd/system/other@templ1.target.requires/templ1@two.service"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------removal of relative enablement symlinks-----------------'
shared/install: also remove symlinks like .wants/foo@one.service → ../foo@one.service So far 'systemctl enable' would create absolute links to the target template name. And we would remove such symlinks just fine. But the user may create symlinks manually in a different form. In particular, symlinks for instanced units *must* have the instance in the source name, and then it is natural to also include it in the target name (.wants/foo@one.service → ../foo@one.service rather than .wants/foo@one.service → ../foo@.service). We would choke on such links, or not remove them at all. A test is added: before: + build-rawhide/systemctl --root=/tmp/systemctl-test.001xda disable templ1@.service Removed "/tmp/systemctl-test.001xda/etc/systemd/system/services.target.wants/templ1@seven.service". Removed "/tmp/systemctl-test.001xda/etc/systemd/system/services.target.wants/templ1@six.service". Removed "/tmp/systemctl-test.001xda/etc/systemd/system/services.target.wants/templ1@five.service". Removed "/tmp/systemctl-test.001xda/etc/systemd/system/services.target.wants/templ1@four.service". Removed "/tmp/systemctl-test.001xda/etc/systemd/system/services.target.wants/templ1@three.service". Failed to disable unit, refusing to operate on linked unit file /tmp/systemctl-test.001xda/etc/systemd/system/services.target.wants/templ1@two.service. Failed to disable unit, refusing to operate on linked unit file /tmp/systemctl-test.001xda/etc/systemd/system/services.target.wants/templ1@two.service. after: + build-rawhide/systemctl --root=/tmp/systemctl-test.QVP0ev disable templ1@.service Removed "/tmp/systemctl-test.QVP0ev/etc/systemd/system/services.target.wants/templ1@seven.service". Removed "/tmp/systemctl-test.QVP0ev/etc/systemd/system/services.target.wants/templ1@six.service". Removed "/tmp/systemctl-test.QVP0ev/etc/systemd/system/services.target.wants/templ1@five.service". Removed "/tmp/systemctl-test.QVP0ev/etc/systemd/system/services.target.wants/templ1@four.service". Removed "/tmp/systemctl-test.QVP0ev/etc/systemd/system/services.target.wants/templ1@three.service". Removed "/tmp/systemctl-test.QVP0ev/etc/systemd/system/services.target.wants/templ1@two.service". Removed "/tmp/systemctl-test.QVP0ev/etc/systemd/system/services.target.wants/templ1@one.service". + test '!' -h /tmp/systemctl-test.QVP0ev/etc/systemd/system/services.target.wants/templ1@one.service + test '!' -h /tmp/systemctl-test.QVP0ev/etc/systemd/system/services.target.wants/templ1@two.service + test '!' -h /tmp/systemctl-test.QVP0ev/etc/systemd/system/services.target.wants/templ1@three.service + test '!' -h /tmp/systemctl-test.QVP0ev/etc/systemd/system/services.target.wants/templ1@four.service + test '!' -h /tmp/systemctl-test.QVP0ev/etc/systemd/system/services.target.wants/templ1@five.service + test '!' -h /tmp/systemctl-test.QVP0ev/etc/systemd/system/services.target.wants/templ1@six.service + test '!' -h /tmp/systemctl-test.QVP0ev/etc/systemd/system/services.target.wants/templ1@seven.service
2022-03-16 11:51:24 +03:00
test ! -h "$root/etc/systemd/system/services.target.wants/templ1@.service"
ln -s '../templ1@one.service' "$root/etc/systemd/system/services.target.wants/templ1@one.service"
ln -s 'templ1@two.service' "$root/etc/systemd/system/services.target.wants/templ1@two.service"
ln -s '../templ1@.service' "$root/etc/systemd/system/services.target.wants/templ1@three.service"
ln -s 'templ1@.service' "$root/etc/systemd/system/services.target.wants/templ1@four.service"
ln -s '/usr/lib/systemd/system/templ1@.service' "$root/etc/systemd/system/services.target.wants/templ1@five.service"
ln -s '/etc/systemd/system/templ1@.service' "$root/etc/systemd/system/services.target.wants/templ1@six.service"
ln -s '/run/system/templ1@.service' "$root/etc/systemd/system/services.target.wants/templ1@seven.service"
# this should remove all links
"$systemctl" --root="$root" disable 'templ1@.service'
test ! -h "$root/etc/systemd/system/services.target.wants/templ1@one.service"
test ! -h "$root/etc/systemd/system/services.target.wants/templ1@two.service"
test ! -h "$root/etc/systemd/system/services.target.wants/templ1@three.service"
test ! -h "$root/etc/systemd/system/services.target.wants/templ1@four.service"
test ! -h "$root/etc/systemd/system/services.target.wants/templ1@five.service"
test ! -h "$root/etc/systemd/system/services.target.wants/templ1@six.service"
test ! -h "$root/etc/systemd/system/services.target.wants/templ1@seven.service"
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------template enablement for another template----------------'
man: fix invalid description of template handling in WantedBy= We don't need to talk about Alias=. The approach of using Alias= to enable units is still supported, but hasn't been advertised as the way to do thing for many years. Using it as an explanation is just confusing. Also, the description of templated units did not take DefaultInstance= into account. It is updated and extended.
2022-03-10 23:33:25 +03:00
cat >"$root/etc/systemd/system/templ2@.service" <<EOF
[Install]
RequiredBy=another-template@.target
EOF
"$systemctl" --root="$root" enable 'templ2@.service'
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
islink "$root/etc/systemd/system/another-template@.target.requires/templ2@.service" "/etc/systemd/system/templ2@.service"
man: fix invalid description of template handling in WantedBy= We don't need to talk about Alias=. The approach of using Alias= to enable units is still supported, but hasn't been advertised as the way to do thing for many years. Using it as an explanation is just confusing. Also, the description of templated units did not take DefaultInstance= into account. It is updated and extended.
2022-03-10 23:33:25 +03:00
"$systemctl" --root="$root" enable 'templ2@two.service'
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
islink "$root/etc/systemd/system/another-template@.target.requires/templ2@.service" "/etc/systemd/system/templ2@.service"
islink "$root/etc/systemd/system/another-template@.target.requires/templ2@two.service" "/etc/systemd/system/templ2@.service"
man: fix invalid description of template handling in WantedBy= We don't need to talk about Alias=. The approach of using Alias= to enable units is still supported, but hasn't been advertised as the way to do thing for many years. Using it as an explanation is just confusing. Also, the description of templated units did not take DefaultInstance= into account. It is updated and extended.
2022-03-10 23:33:25 +03:00
"$systemctl" --root="$root" disable 'templ2@other.service'
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
islink "$root/etc/systemd/system/another-template@.target.requires/templ2@.service" "/etc/systemd/system/templ2@.service"
islink "$root/etc/systemd/system/another-template@.target.requires/templ2@two.service" "/etc/systemd/system/templ2@.service"
man: fix invalid description of template handling in WantedBy= We don't need to talk about Alias=. The approach of using Alias= to enable units is still supported, but hasn't been advertised as the way to do thing for many years. Using it as an explanation is just confusing. Also, the description of templated units did not take DefaultInstance= into account. It is updated and extended.
2022-03-10 23:33:25 +03:00
"$systemctl" --root="$root" disable 'templ2@two.service'
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
islink "$root/etc/systemd/system/another-template@.target.requires/templ2@.service" "/etc/systemd/system/templ2@.service"
man: fix invalid description of template handling in WantedBy= We don't need to talk about Alias=. The approach of using Alias= to enable units is still supported, but hasn't been advertised as the way to do thing for many years. Using it as an explanation is just confusing. Also, the description of templated units did not take DefaultInstance= into account. It is updated and extended.
2022-03-10 23:33:25 +03:00
test ! -h "$root/etc/systemd/system/another-template@.target.requires/templ2@two.service"
"$systemctl" --root="$root" disable 'templ2@.service'
test ! -h "$root/etc/systemd/system/another-template@.target.requires/templ2@.service"
test ! -h "$root/etc/systemd/system/another-template@.target.requires/templ2@two.service"
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------aliases w/ and w/o instance-----------------------------'
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test ! -e "$root/etc/systemd/system/link4.service"
cat >"$root/etc/systemd/system/link4.service" <<EOF
[Install]
shared/install: also check for self-aliases during installation and ignore them We had a check that was done in unit_file_resolve_symlink(). Let's move the check to unit_validate_alias_symlink_or_warn(), which makes it available to the code in install.c. With this, unit_file_resolve_symlink() behaves almost the same. The warning about "suspicious symlink" is done a bit later. I think this should be OK.
2022-03-10 22:26:59 +03:00
Alias=link4.service
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
Alias=link4@.service
Alias=link4@inst.service
Alias=link4alias.service
Alias=link4alias2.service
EOF
test-systemctl-enable: use magic syntax to allow inverted tests Inspired by 7910ec3bcde2ee0086b3e49f8aaa2a9f13f58d97. '! true' passes, because it's a conditional expression. But '( ! true )' fails, because '( … )' creates a subshell, i.e. a separate program, and '! true' becomes the return value of that program, and the whole thing apparently is not a conditional expression for the outer shell. This is shorter, so let's just do this.
2022-03-25 17:56:16 +03:00
( ! "$systemctl" --root="$root" enable 'link4.service' )
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test ! -h "$root/etc/systemd/system/link4.service" # this is our file
test ! -h "$root/etc/systemd/system/link4@.service"
test ! -h "$root/etc/systemd/system/link4@inst.service"
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
islink "$root/etc/systemd/system/link4alias.service" "/etc/systemd/system/link4.service"
islink "$root/etc/systemd/system/link4alias2.service" "/etc/systemd/system/link4.service"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
"$systemctl" --root="$root" disable 'link4.service'
test ! -h "$root/etc/systemd/system/link4.service"
test ! -h "$root/etc/systemd/system/link4@.service"
test ! -h "$root/etc/systemd/system/link4@inst.service"
test ! -h "$root/etc/systemd/system/link4alias.service"
test ! -h "$root/etc/systemd/system/link4alias2.service"
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------systemctl enable on path to unit file-------------------'
shared/install: return failure when enablement fails, but process as much as possible So far we'd issue a warning (before this series, just in the logs on the server side, and before this commit, on stderr on the caller's side), but return success. It seems that successfull return was introduced by mistake in aa0f357fd833feecbea6c3e9be80b643e433bced (my fault :( ), which was supposed to be a refactoring without a functional change. I think it's better to fail, because if enablement fails, the user will most likely want to diagnose the issue. Note that we still do partial enablement, as far as that is possible. So if e.g. we have [Install] Alias=foo.service foobar, we'll create the symlink 'foo.service', but not 'foobar', since that's not a valid unit name. We'll print info about the action taken, and about 'foobar' being invalid, and return failure.
2022-03-10 17:47:12 +03:00
cat >"$root/etc/systemd/system/link4.service" <<EOF
[Install]
Alias=link4alias.service
Alias=link4alias2.service
EOF
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
# Apparently this works. I'm not sure what to think.
"$systemctl" --root="$root" enable '/etc/systemd/system/link4.service'
test ! -h "$root/etc/systemd/system/link4.service" # this is our file
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
islink "$root/etc/systemd/system/link4alias.service" "/etc/systemd/system/link4.service"
islink "$root/etc/systemd/system/link4alias2.service" "/etc/systemd/system/link4.service"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
"$systemctl" --root="$root" disable '/etc/systemd/system/link4.service'
test ! -h "$root/etc/systemd/system/link4.service"
test ! -h "$root/etc/systemd/system/link4alias.service"
test ! -h "$root/etc/systemd/system/link4alias2.service"
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------issue 661: enable on unit file--------------------------'
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test ! -e "$root/etc/systemd/system/link5.service"
cat >"$root/etc/systemd/system/link5.service" <<EOF
[Install]
shared/install: also check for self-aliases during installation and ignore them We had a check that was done in unit_file_resolve_symlink(). Let's move the check to unit_validate_alias_symlink_or_warn(), which makes it available to the code in install.c. With this, unit_file_resolve_symlink() behaves almost the same. The warning about "suspicious symlink" is done a bit later. I think this should be OK.
2022-03-10 22:26:59 +03:00
Alias=link5.service
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
Alias=link5alias.service
Alias=link5alias2.service
EOF
"$systemctl" --root="$root" enable 'link5.service'
test ! -h "$root/etc/systemd/system/link5.service" # this is our file
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
islink "$root/etc/systemd/system/link5alias.service" "/etc/systemd/system/link5.service"
islink "$root/etc/systemd/system/link5alias2.service" "/etc/systemd/system/link5.service"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
"$systemctl" --root="$root" disable 'link5.service'
test ! -h "$root/etc/systemd/system/link5alias.service"
test ! -h "$root/etc/systemd/system/link5alias2.service"
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------issue 661: link and enable on unit file-----------------'
test-systemctl-enable: enhance the test for unit file linking Current behaviour is wrong, but it cannot be shown in this test, because we don't have a running systemd instance here.
2022-03-15 19:45:34 +03:00
test ! -e "$root/etc/systemd/system/link5copy.service"
cat >"$root/link5copy.service" <<EOF
[Install]
Alias=link5copy.service
Alias=link5alias.service
Alias=link5alias2.service
EOF
test ! -e "$root/etc/systemd/system/link5copy.service"
"$systemctl" --root="$root" link '/link5copy.service'
islink "$root/etc/systemd/system/link5copy.service" '/link5copy.service'
test ! -h "$root/etc/systemd/system/link5alias.service"
test ! -h "$root/etc/systemd/system/link5alias2.service"
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
# FIXME: we must create link5alias2 and link5alias as relative links to link5.service
# When they are independent links to /link5.service, systemd doesn't know that
# they are aliases, because we do not follow symlinks outside of the search paths.
test-systemctl-enable: enhance the test for unit file linking Current behaviour is wrong, but it cannot be shown in this test, because we don't have a running systemd instance here.
2022-03-15 19:45:34 +03:00
"$systemctl" --root="$root" disable 'link5copy.service'
test ! -h "$root/etc/systemd/system/link5copy.service"
test ! -h "$root/etc/systemd/system/link5alias.service"
test ! -h "$root/etc/systemd/system/link5alias2.service"
"$systemctl" --root="$root" enable '/link5copy.service'
islink "$root/etc/systemd/system/link5copy.service" '/link5copy.service'
shared/install: correctly install alias for units outside search path Currently, if a unit file is enabled from outside of the search path, and that unit has an alias, then the symlink ends up pointing outside of the search path too. For example: $ cat /tmp/a.service [Service] ExecStart=sleep infinity [Install] Alias=b.service WantedBy=multi-user.target $ systemctl enable /tmp/a.service Created symlink /etc/systemd/system/a.service → /tmp/a.service. Created symlink /etc/systemd/system/b.service → /tmp/a.service. Created symlink /etc/systemd/system/multi-user.target.wants/a.service → /tmp/a.service. This then means the alias is treated as a separate unit: $ systemctl start a.service $ sudo systemctl status a ● a.service Loaded: loaded (/etc/systemd/system/a.service; enabled; preset: enabled) Active: active (running) since Fri 2024-03-15 15:17:49 EDT; 9s ago Main PID: 769593 (sleep) Tasks: 1 (limit: 18898) Memory: 220.0K CPU: 5ms CGroup: /system.slice/a.service └─769593 sleep infinity Mar 15 15:17:49 six systemd[1]: Started a.service. $ sudo systemctl status b ○ b.service Loaded: loaded (/etc/systemd/system/b.service; alias) Active: inactive (dead) To fix this, make sure the alias uses a target that is inside the search path. Since the unit file itself is outside of the search path, a symlink inside the search path will have been created already. Hence, just point the alias symlink to that recently created symlink.
2024-03-15 22:14:05 +03:00
islink "$root/etc/systemd/system/link5alias.service" '/etc/systemd/system/link5copy.service'
islink "$root/etc/systemd/system/link5alias2.service" '/etc/systemd/system/link5copy.service'
test-systemctl-enable: enhance the test for unit file linking Current behaviour is wrong, but it cannot be shown in this test, because we don't have a running systemd instance here.
2022-03-15 19:45:34 +03:00
"$systemctl" --root="$root" disable 'link5copy.service'
test ! -h "$root/etc/systemd/system/link5copy.service"
test ! -h "$root/etc/systemd/system/link5alias.service"
test ! -h "$root/etc/systemd/system/link5alias2.service"
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------issue 19437: plain templates in .wants/ or .requires/---'
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test ! -e "$root/etc/systemd/system/link5@.path"
cat >"$root/etc/systemd/system/link5@.path" <<EOF
[Install]
WantedBy=target5@.target
RequiredBy=target5@.target
WantedBy=target5@inst.target
RequiredBy=target5@inst.target
EOF
"$systemctl" --root="$root" enable 'link5@.path'
test ! -h "$root/etc/systemd/system/link5@.path" # this is our file
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
islink "$root/etc/systemd/system/target5@.target.wants/link5@.path" "/etc/systemd/system/link5@.path"
islink "$root/etc/systemd/system/target5@.target.requires/link5@.path" "/etc/systemd/system/link5@.path"
islink "$root/etc/systemd/system/target5@inst.target.wants/link5@.path" "/etc/systemd/system/link5@.path"
islink "$root/etc/systemd/system/target5@inst.target.requires/link5@.path" "/etc/systemd/system/link5@.path"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
"$systemctl" --root="$root" disable 'link5@.path'
test ! -h "$root/etc/systemd/system/link5@.path" # this is our file
test ! -h "$root/etc/systemd/system/target5@.target.wants/link5@.path"
test ! -h "$root/etc/systemd/system/target5@.target.requires/link5@.path"
test ! -h "$root/etc/systemd/system/target5@inst.target.wants/link5@.path"
test ! -h "$root/etc/systemd/system/target5@inst.target.requires/link5@.path"
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------removal of symlinks not listed in [Install]-------------'
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
# c.f. 66a19d85a533b15ed32f4066ec880b5a8c06babd
test ! -e "$root/etc/systemd/system/multilink.mount"
cat >"$root/etc/systemd/system/multilink.mount" <<EOF
[Install]
WantedBy=multilink.target
EOF
mkdir -p "$root/etc/systemd/system/default.target.wants"
ln -s ../multilink.mount "$root/etc/systemd/system/default.target.wants/"
ln -s ../multilink.mount "$root/etc/systemd/system/multilink-alias.mount"
ln -s ../multilink.mount "$root/etc/systemd/system/multilink-badalias.service"
"$systemctl" --root="$root" disable 'multilink.mount'
test -e "$root/etc/systemd/system/multilink.mount" # this is our file
test ! -h "$root/etc/systemd/system/default.target.wants/"
test ! -h "$root/etc/systemd/system/multilink-alias.mount"
test ! -h "$root/etc/systemd/system/multilink-badalias.service"
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------merge 20017: specifiers in the unit file----------------'
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test ! -e "$root/etc/systemd/system/some-some-link6@.socket"
# c.f. de61a04b188f81a85cdb5c64ddb4987dcd9d30d3
check_alias() {
test-systemctl-enable: make shellcheck happy Quoting is not necessary in many places, but I think it's nicer to use it consistently.
2022-03-24 13:52:35 +03:00
: "------------------ %$1 -------------------------------------"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
cat >"$root/etc/systemd/system/some-some-link6@.socket" <<EOF
[Install]
Alias=target@$1:%$1.socket
EOF
SYSTEMD_LOG_LEVEL=debug "$systemctl" --root="$root" enable 'some-some-link6@.socket' || return 1
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
islink "$root/etc/systemd/system/target@$1:$2.socket" "/etc/systemd/system/some-some-link6@.socket" || return 2
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
}
test-systemctl-enable: disable the test for %a for now
2022-03-28 21:20:09 +03:00
# TODO: our architecture names are different than what uname -m returns.
# Add something like 'systemd-detect-virt --print-architecture' and use it here.
check_alias a "$(uname -m | tr '_' '-')" || :
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
shared/specifier: provide proper error messages when specifiers fail to read files ENOENT is easily confused with the file that we're working on not being present, e.g. when the file contains %o or something else that requires os-release to be present. Let's use -EUNATCH instead to reduce that chances of confusion if the context of the error is lost. And once we have pinpointed the reason, let's provide a proper error message: + build/systemctl --root=/tmp/systemctl-test.TO7Mcb enable some-some-link6@.socket /tmp/systemctl-test.TO7Mcb/etc/systemd/system/some-some-link6@.socket: Failed to resolve alias "target@A:%A.socket": Protocol driver not attached Failed to enable unit, cannot resolve specifiers in "target@A:%A.socket".
2022-03-08 14:08:00 +03:00
test ! -e "$root/etc/os-release"
test ! -e "$root/usr/lib/os-release"
test-systemctl-enable: use magic syntax to allow inverted tests Inspired by 7910ec3bcde2ee0086b3e49f8aaa2a9f13f58d97. '! true' passes, because it's a conditional expression. But '( ! true )' fails, because '( … )' creates a subshell, i.e. a separate program, and '! true' becomes the return value of that program, and the whole thing apparently is not a conditional expression for the outer shell. This is shorter, so let's just do this.
2022-03-25 17:56:16 +03:00
( ! check_alias A '' )
( ! check_alias B '' )
( ! check_alias M '' )
( ! check_alias o '' )
( ! check_alias w '' )
( ! check_alias W '' )
shared/specifier: provide proper error messages when specifiers fail to read files ENOENT is easily confused with the file that we're working on not being present, e.g. when the file contains %o or something else that requires os-release to be present. Let's use -EUNATCH instead to reduce that chances of confusion if the context of the error is lost. And once we have pinpointed the reason, let's provide a proper error message: + build/systemctl --root=/tmp/systemctl-test.TO7Mcb enable some-some-link6@.socket /tmp/systemctl-test.TO7Mcb/etc/systemd/system/some-some-link6@.socket: Failed to resolve alias "target@A:%A.socket": Protocol driver not attached Failed to enable unit, cannot resolve specifiers in "target@A:%A.socket".
2022-03-08 14:08:00 +03:00
cat >"$root/etc/os-release" <<EOF
# empty
EOF
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
shared/specifier: provide proper error messages when specifiers fail to read files ENOENT is easily confused with the file that we're working on not being present, e.g. when the file contains %o or something else that requires os-release to be present. Let's use -EUNATCH instead to reduce that chances of confusion if the context of the error is lost. And once we have pinpointed the reason, let's provide a proper error message: + build/systemctl --root=/tmp/systemctl-test.TO7Mcb enable some-some-link6@.socket /tmp/systemctl-test.TO7Mcb/etc/systemd/system/some-some-link6@.socket: Failed to resolve alias "target@A:%A.socket": Protocol driver not attached Failed to enable unit, cannot resolve specifiers in "target@A:%A.socket".
2022-03-08 14:08:00 +03:00
check_alias A ''
check_alias B ''
check_alias M ''
check_alias o ''
check_alias w ''
check_alias W ''
cat >"$root/etc/os-release" <<EOF
ID='the-id'
VERSION_ID=39a
BUILD_ID=build-id
VARIANT_ID=wrong
VARIANT_ID=right
IMAGE_ID="foobar"
IMAGE_VERSION='1-2-3'
EOF
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
shared/specifier: provide proper error messages when specifiers fail to read files ENOENT is easily confused with the file that we're working on not being present, e.g. when the file contains %o or something else that requires os-release to be present. Let's use -EUNATCH instead to reduce that chances of confusion if the context of the error is lost. And once we have pinpointed the reason, let's provide a proper error message: + build/systemctl --root=/tmp/systemctl-test.TO7Mcb enable some-some-link6@.socket /tmp/systemctl-test.TO7Mcb/etc/systemd/system/some-some-link6@.socket: Failed to resolve alias "target@A:%A.socket": Protocol driver not attached Failed to enable unit, cannot resolve specifiers in "target@A:%A.socket".
2022-03-08 14:08:00 +03:00
check_alias A '1-2-3'
check_alias B 'build-id'
check_alias M 'foobar'
check_alias o 'the-id'
check_alias w '39a'
check_alias W 'right'
test-systemctl-enable: also use freshly-built systemd-id128 Tests were failing on centos7 because systemd-id128 is not in path.
2022-03-28 21:03:37 +03:00
check_alias b "$("$systemd_id128" boot-id)"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
shared/install: provide proper error messages when invalid specifiers are used $ build/systemctl --root=/tmp/systemctl-test.KXY8fu enable some-some-link6@.socket Failed to enable unit, invalid specifier in "target@C:%C.socket".
2022-03-09 18:06:24 +03:00
# Specifiers not available for [Install]
test-systemctl-enable: use magic syntax to allow inverted tests Inspired by 7910ec3bcde2ee0086b3e49f8aaa2a9f13f58d97. '! true' passes, because it's a conditional expression. But '( ! true )' fails, because '( … )' creates a subshell, i.e. a separate program, and '! true' becomes the return value of that program, and the whole thing apparently is not a conditional expression for the outer shell. This is shorter, so let's just do this.
2022-03-25 17:56:16 +03:00
( ! check_alias C '' )
( ! check_alias E '' )
( ! check_alias f '' )
( ! check_alias h '' )
( ! check_alias I '' )
( ! check_alias J '' )
( ! check_alias L '' )
( ! check_alias P '' )
( ! check_alias s '' )
( ! check_alias S '' )
( ! check_alias t '' )
( ! check_alias T '' )
( ! check_alias V '' )
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
shared/specifier: fix %u/%U/%g/%G when called as unprivileged user We would resolve those specifiers to the calling user/group. This is mostly OK when done in the manager, because the manager generally operates as root in system mode, and a non-root in user mode. It would still be wrong if called with --test though. But in systemctl, this would be generally wrong, since we can call 'systemctl --system' as a normal user, either for testing or even for actual operation with '--root=…'. When operating in --global mode, %u/%U/%g/%G should return an error. The information whether we're operating in system mode, user mode, or global mode is passed as the data pointer to specifier_group_name(), specifier_user_name(), specifier_group_id(), specifier_user_id(). We can't use userdata, because it's already used for other things.
2022-03-10 00:29:19 +03:00
check_alias g root
check_alias G 0
check_alias u root
check_alias U 0
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
check_alias i ""
check_alias j 'link6'
check_alias l "$(uname -n | sed 's/\..*//')"
shared/specifier: provide proper error messages when specifiers fail to read files ENOENT is easily confused with the file that we're working on not being present, e.g. when the file contains %o or something else that requires os-release to be present. Let's use -EUNATCH instead to reduce that chances of confusion if the context of the error is lost. And once we have pinpointed the reason, let's provide a proper error message: + build/systemctl --root=/tmp/systemctl-test.TO7Mcb enable some-some-link6@.socket /tmp/systemctl-test.TO7Mcb/etc/systemd/system/some-some-link6@.socket: Failed to resolve alias "target@A:%A.socket": Protocol driver not attached Failed to enable unit, cannot resolve specifiers in "target@A:%A.socket".
2022-03-08 14:08:00 +03:00
test ! -e "$root/etc/machine-id"
test-systemctl-enable: use magic syntax to allow inverted tests Inspired by 7910ec3bcde2ee0086b3e49f8aaa2a9f13f58d97. '! true' passes, because it's a conditional expression. But '( ! true )' fails, because '( … )' creates a subshell, i.e. a separate program, and '! true' becomes the return value of that program, and the whole thing apparently is not a conditional expression for the outer shell. This is shorter, so let's just do this.
2022-03-25 17:56:16 +03:00
( ! check_alias m '' )
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test-systemctl-enable: also use freshly-built systemd-id128 Tests were failing on centos7 because systemd-id128 is not in path.
2022-03-28 21:03:37 +03:00
"$systemd_id128" new >"$root/etc/machine-id"
shared/specifier: provide proper error messages when specifiers fail to read files ENOENT is easily confused with the file that we're working on not being present, e.g. when the file contains %o or something else that requires os-release to be present. Let's use -EUNATCH instead to reduce that chances of confusion if the context of the error is lost. And once we have pinpointed the reason, let's provide a proper error message: + build/systemctl --root=/tmp/systemctl-test.TO7Mcb enable some-some-link6@.socket /tmp/systemctl-test.TO7Mcb/etc/systemd/system/some-some-link6@.socket: Failed to resolve alias "target@A:%A.socket": Protocol driver not attached Failed to enable unit, cannot resolve specifiers in "target@A:%A.socket".
2022-03-08 14:08:00 +03:00
check_alias m "$(cat "$root/etc/machine-id")"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
check_alias n 'some-some-link6@.socket'
check_alias N 'some-some-link6@'
check_alias p 'some-some-link6'
test-systemctl-enable: skip test for %v if kver is not a valid instance On arm, we'd fail with: target@v:5.16.8-200.fc35.armv7hl+lpae.socket: not a valid unit name "target@v:5.16.8-200.fc35.armv7hl+lpae.socket": Invalid argument
2022-03-29 23:39:08 +03:00
uname -r | grep -q '[^a-zA-Z0-9_.\\-]' || \
check_alias v "$(uname -r)"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test-systemctl-enable: use magic syntax to allow inverted tests Inspired by 7910ec3bcde2ee0086b3e49f8aaa2a9f13f58d97. '! true' passes, because it's a conditional expression. But '( ! true )' fails, because '( … )' creates a subshell, i.e. a separate program, and '! true' becomes the return value of that program, and the whole thing apparently is not a conditional expression for the outer shell. This is shorter, so let's just do this.
2022-03-25 17:56:16 +03:00
# % is not legal in unit name
( ! check_alias % '%' )
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test-systemctl-enable: use magic syntax to allow inverted tests Inspired by 7910ec3bcde2ee0086b3e49f8aaa2a9f13f58d97. '! true' passes, because it's a conditional expression. But '( ! true )' fails, because '( … )' creates a subshell, i.e. a separate program, and '! true' becomes the return value of that program, and the whole thing apparently is not a conditional expression for the outer shell. This is shorter, so let's just do this.
2022-03-25 17:56:16 +03:00
# %z is not defined
( ! check_alias z 'z' )
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------specifiers in WantedBy----------------------------------'
man: fix invalid description of template handling in WantedBy= We don't need to talk about Alias=. The approach of using Alias= to enable units is still supported, but hasn't been advertised as the way to do thing for many years. Using it as an explanation is just confusing. Also, the description of templated units did not take DefaultInstance= into account. It is updated and extended.
2022-03-10 23:33:25 +03:00
# We don't need to repeat all the tests. Let's do a basic check that specifier
# expansion is performed.
cat >"$root/etc/systemd/system/some-some-link7.socket" <<EOF
[Install]
WantedBy=target@%p.target
WantedBy=another-target@.target
RequiredBy=target2@%p.target
RequiredBy=another-target2@.target
EOF
"$systemctl" --root="$root" enable 'some-some-link7.socket'
Revert "shared/install: create relative symlinks for enablement and aliasing" This reverts commit d6c9411072901556176ac130f2ce71a33107aa93. I still think this is something that needs to be done, but we're hitting some unexplained failures, e.g. https://github.com/systemd/systemd/issues/22920. So let's revert this for now, so -rc2 can be released, with a plan to return to this after a release. Closes #22920.
2022-04-12 23:01:10 +03:00
islink "$root/etc/systemd/system/target@some-some-link7.target.wants/some-some-link7.socket" "/etc/systemd/system/some-some-link7.socket"
islink "$root/etc/systemd/system/another-target@.target.wants/some-some-link7.socket" "/etc/systemd/system/some-some-link7.socket"
islink "$root/etc/systemd/system/target2@some-some-link7.target.requires/some-some-link7.socket" "/etc/systemd/system/some-some-link7.socket"
islink "$root/etc/systemd/system/another-target2@.target.requires/some-some-link7.socket" "/etc/systemd/system/some-some-link7.socket"
man: fix invalid description of template handling in WantedBy= We don't need to talk about Alias=. The approach of using Alias= to enable units is still supported, but hasn't been advertised as the way to do thing for many years. Using it as an explanation is just confusing. Also, the description of templated units did not take DefaultInstance= into account. It is updated and extended.
2022-03-10 23:33:25 +03:00
"$systemctl" --root="$root" disable 'some-some-link7.socket'
test ! -h "$root/etc/systemd/system/target@some-some-link7.target.wants/some-some-link7.socket"
test ! -h "$root/etc/systemd/system/another-target@.target.wants/some-some-link7.socket"
test ! -h "$root/etc/systemd/system/target2@some-some-link7.target.requires/some-some-link7.socket"
test ! -h "$root/etc/systemd/system/another-target2@.target.requires/some-some-link7.socket"
test: add test for systemctl link & enable This test has overlap with test-install-root, but it tests things at a different level, so I think it's useful to add. It immediately shows various bugs which will be fixed in later patches.
2022-03-07 14:15:42 +03:00
# TODO: repeat the tests above for presets
basic: add new variable $SYSTEMD_OS_RELEASE to override location of os-release The test for the variable is added in test-systemctl-enable because there we can do it almost for free, and the variable is most likely to be used with 'systemctl enable --root' anyway.
2022-03-07 20:54:50 +03:00
test-systemctl-enable: make titles more consistent
2023-12-18 09:26:31 +03:00
: '-------SYSTEMD_OS_RELEASE relative to root---------------------'
basic: add new variable $SYSTEMD_OS_RELEASE to override location of os-release The test for the variable is added in test-systemctl-enable because there we can do it almost for free, and the variable is most likely to be used with 'systemctl enable --root' anyway.
2022-03-07 20:54:50 +03:00
# check that os-release overwriting works as expected with root
test -e "$root/etc/os-release"
cat >"$root/etc/os-release2" <<EOF
ID='the-id2'
EOF
os-util: make $SYSTEMD_OS_RELEASE prefixed with the root directory To make it consistent with other env vars, e.g. $SYSTEMD_ESP_PATH or $SYSTEMD_XBOOTLDR_PATH. This is useful when the root is specified by a file descriptor, instead of a path.
2023-04-08 16:33:40 +03:00
SYSTEMD_OS_RELEASE="/etc/os-release2" check_alias o 'the-id2'
Copy Permalink