** Also affects: systemd (Ubuntu Focal)
Importance: Undecided
Status: New
** Also affects: systemd (Ubuntu Jammy)
Importance: Undecided
Status: New
** Also affects: systemd (Ubuntu Mantic)
Importance: Undecided
Status: New
** Changed in: systemd (Ubuntu Mantic)
Status: New => Won't Fix
** Changed in: systemd (Ubuntu Focal)
Status: New => Confirmed
** Changed in: systemd (Ubuntu Jammy)
Status: New => Confirmed
** Changed in: systemd (Ubuntu Focal)
Importance: Undecided => Wishlist
** Changed in: systemd (Ubuntu Jammy)
Importance: Undecided => Wishlist
** Changed in: systemd (Ubuntu)
Importance: Wishlist => Medium
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2057768
Title:
Unit and its Alias appear to be separate entities when enabling the
unit by filepath
Status in systemd package in Ubuntu:
Triaged
Status in systemd source package in Focal:
Confirmed
Status in systemd source package in Jammy:
Confirmed
Status in systemd source package in Mantic:
Won't Fix
Bug description:
### systemd version the issue has been seen with
245
### Used distribution
Linux Mint 20.1 and Ubuntu 20.04
### Linux kernel version used
5.4.0-135-generic
### CPU architectures issue was seen on
None
### Component
systemctl
### Expected behaviour you didn't see
When including an alias in a unit file that is enabled by referring to
its filepath, its alias should refer to the unit - the two should refer
to the exact same service. This is the case when the unit file is
enabled inside one of the systemd directories. I expect alias and unit
to refer to one identical service also when enabling via filepath.
In particular, the output of `systemctl status ...` should be identical
for a Unit and its Alias.
### Unexpected behaviour you saw
After passing a systemd unit including an alias to `systemctl enable
PATH...` by path, systemctl treated the unit and its alias as separate
units.
Specifically, `systemctl status` reports different results
(running/inactive, PID if applicable) for the unit name and its alias.
When I start the unit by its original name, only the status of the unit
is reported as running while the status of the alias remains inactive,
and vice versa. After starting the Alias too, two services with
different PIDs are running.
(When copying the unit into /etc/systemd/system/ and running `systemctl
enable UNIT...` this issue does not occur and alias and unit behave the
same.)
### Steps to reproduce the problem
```
~$ cat dummy.service
[Service]
ExecStart=tail -f /dev/null
[Install]
Alias=dumb.service
~$ sudo systemctl enable ~/dummy.service
Created symlink /etc/systemd/system/dumb.service →
/home/lukas/dummy.service.
Created symlink /etc/systemd/system/dummy.service →
/home/lukas/dummy.service.
~$ sudo systemctl start dummy
~$ systemctl status dummy
● dummy.service
Loaded: loaded (/etc/systemd/system/dummy.service; enabled; vendor
preset:>
Active: active (running) since Tue 2024-03-12 15:36:58 CET; 8s ago
Main PID: 159809 (tail)
Tasks: 1 (limit: 76978)
Memory: 160.0K
CGroup: /system.slice/dummy.service
└─159809 /usr/bin/tail -f /dev/null
Mär 12 15:36:58 MyMachine systemd[1]: Started dummy.service.
~$ systemctl status dumb
● dumb.service
Loaded: loaded (/etc/systemd/system/dumb.service; enabled; vendor
preset: >
Active: inactive (dead)
Mär 12 15:30:53 MyMachine systemd[1]: Started dumb.service.
Mär 12 15:31:16 MyMachine systemd[1]: Stopping dumb.service...
Mär 12 15:31:16 MyMachine systemd[1]: dumb.service: Succeeded.
Mär 12 15:31:16 MyMachine systemd[1]: Stopped dumb.service.
~$
```
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2057768/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
