Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #268799 > unrolled thread

inconsistency in the symlinks under /etc/systemd

Started byVincent Lefevre <vincent@vinc17.net>
First post2024-04-10 13:10 +0200
Last post2024-04-12 21:10 +0200
Articles 9 — 4 participants

Back to article view | Back to linux.debian.user

Contents

  inconsistency in the symlinks under /etc/systemd Vincent Lefevre <vincent@vinc17.net> - 2024-04-10 13:10 +0200
    Re: inconsistency in the symlinks under /etc/systemd Dan Purgert <dan@djph.net> - 2024-04-10 16:20 +0200
      Re: inconsistency in the symlinks under /etc/systemd Vincent Lefevre <vincent@vinc17.net> - 2024-04-11 04:10 +0200
        Re: inconsistency in the symlinks under /etc/systemd Vincent Lefevre <vincent@vinc17.net> - 2024-04-11 19:50 +0200
          Re: inconsistency in the symlinks under /etc/systemd David Wright <deblis@lionunicorn.co.uk> - 2024-04-12 21:10 +0200
        Re: inconsistency in the symlinks under /etc/systemd David Wright <deblis@lionunicorn.co.uk> - 2024-04-11 07:10 +0200
    Re: inconsistency in the symlinks under /etc/systemd David Wright <deblis@lionunicorn.co.uk> - 2024-04-10 16:30 +0200
    Re: inconsistency in the symlinks under /etc/systemd Jeffrey Walton <noloader@gmail.com> - 2024-04-10 21:00 +0200
      Re: inconsistency in the symlinks under /etc/systemd David Wright <deblis@lionunicorn.co.uk> - 2024-04-12 21:10 +0200

#268799 — inconsistency in the symlinks under /etc/systemd

FromVincent Lefevre <vincent@vinc17.net>
Date2024-04-10 13:10 +0200
Subjectinconsistency in the symlinks under /etc/systemd
Message-ID<IrE01-5kDT-3@gated-at.bofh.it>
Hi,

On one machine, I have

lrwxrwxrwx 1 root root 35 2023-10-07 13:43:24 /etc/systemd/system/sockets.target.wants/dm-event.socket -> /lib/systemd/system/dm-event.socket

and on another one, I have

lrwxrwxrwx 1 root root 39 2024-01-05 16:54:09 /etc/systemd/system/sockets.target.wants/dm-event.socket -> /usr/lib/systemd/system/dm-event.socket

These symlinks were created at Debian installation time, and in
both cases, the dmeventd version is 2:1.02.196-1+b1.

Shouldn't the system ensure that symlinks are consistent on different
machines (even though the above symlinks are equivalent), for instance
to ease the comparison of configurations between machines?

For instance, shouldn't usr-is-merged convert the symlinks to a
canonical path?

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [next] | [standalone]

#268801

FromDan Purgert <dan@djph.net>
Date2024-04-10 16:20 +0200
Message-ID<IrGXT-5mlF-3@gated-at.bofh.it>
In reply to#268799

[Multipart message — attachments visible in raw view] — view raw

On Apr 10, 2024, Vincent Lefevre wrote:
> Hi,
> 
> On one machine, I have
> 
> lrwxrwxrwx 1 root root 35 2023-10-07 13:43:24 /etc/systemd/system/sockets.target.wants/dm-event.socket -> /lib/systemd/system/dm-event.socket
> 
> and on another one, I have
> 
> lrwxrwxrwx 1 root root 39 2024-01-05 16:54:09 /etc/systemd/system/sockets.target.wants/dm-event.socket -> /usr/lib/systemd/system/dm-event.socket
> 
> These symlinks were created at Debian installation time, and in
> both cases, the dmeventd version is 2:1.02.196-1+b1.
> 
> Shouldn't the system ensure that symlinks are consistent on different
> machines (even though the above symlinks are equivalent), for instance
> to ease the comparison of configurations between machines?

I'd hazard it's a consequence of usrmerge being the "default state" in
one installation and not the other.

-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1  E067 6D65 70E5 4CE7 2860

[toc] | [prev] | [next] | [standalone]

#268807

FromVincent Lefevre <vincent@vinc17.net>
Date2024-04-11 04:10 +0200
Message-ID<IrS2Z-5t38-1@gated-at.bofh.it>
In reply to#268801
On 2024-04-10 09:52:51 -0400, Dan Purgert wrote:
> I'd hazard it's a consequence of usrmerge being the "default state" in
> one installation and not the other.

Both machines have always been usr-merged (i.e. from the Debian
installation).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [next] | [standalone]

#268809

FromVincent Lefevre <vincent@vinc17.net>
Date2024-04-11 19:50 +0200
Message-ID<Is6IF-5BSN-3@gated-at.bofh.it>
In reply to#268807
On 2024-04-10 23:47:36 -0500, David Wright wrote:
> On Thu 11 Apr 2024 at 03:36:59 (+0200), Vincent Lefevre wrote:
> > On 2024-04-10 09:52:51 -0400, Dan Purgert wrote:
> > > I'd hazard it's a consequence of usrmerge being the "default state" in
> > > one installation and not the other.
> > 
> > Both machines have always been usr-merged (i.e. from the Debian
> > installation).
> 
> This is trixie, is it not, so perhaps bugs are being fixed
> in package installation support programs. You should be able
> to see the symlinks being created in /var/log/apt/term.log*
> if they haven't yet rotated away.

On the first machine:

Setting up dmeventd (2:1.02.185-2) ...
Created symlink /etc/systemd/system/sockets.target.wants/dm-event.socket → /lib/systemd/system/dm-event.socket.
Setting up lvm2 (2.03.16-2) ...
Created symlink /etc/systemd/system/sysinit.target.wants/blk-availability.service → /lib/systemd/system/blk-availability.service.
Created symlink /etc/systemd/system/sysinit.target.wants/lvm2-monitor.service → /lib/systemd/system/lvm2-monitor.service.
Created symlink /etc/systemd/system/sysinit.target.wants/lvm2-lvmpolld.socket → /lib/systemd/system/lvm2-lvmpolld.socket.

On the second machine:

Setting up dmeventd (2:1.02.185-2) ...
Created symlink /etc/systemd/system/sockets.target.wants/dm-event.socket → /usr/lib/systemd/system/dm-event.socket.
Setting up lvm2 (2.03.16-2) ...
Created symlink /etc/systemd/system/sysinit.target.wants/blk-availability.service → /usr/lib/systemd/system/blk-availability.service.
Created symlink /etc/systemd/system/sysinit.target.wants/lvm2-monitor.service → /usr/lib/systemd/system/lvm2-monitor.service.
Created symlink /etc/systemd/system/sysinit.target.wants/lvm2-lvmpolld.socket → /usr/lib/systemd/system/lvm2-lvmpolld.socket.

> Or else, have you run systemctl on dmeventd, in order to change its
> status?

I'm not sure what to do.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [next] | [standalone]

#268829

FromDavid Wright <deblis@lionunicorn.co.uk>
Date2024-04-12 21:10 +0200
Message-ID<IsurD-5QJk-25@gated-at.bofh.it>
In reply to#268809
On Thu 11 Apr 2024 at 19:28:48 (+0200), Vincent Lefevre wrote:
> On 2024-04-10 23:47:36 -0500, David Wright wrote:
> > On Thu 11 Apr 2024 at 03:36:59 (+0200), Vincent Lefevre wrote:
> > > On 2024-04-10 09:52:51 -0400, Dan Purgert wrote:
> > > > I'd hazard it's a consequence of usrmerge being the "default state" in
> > > > one installation and not the other.
> > > 
> > > Both machines have always been usr-merged (i.e. from the Debian
> > > installation).
> > 
> > This is trixie, is it not, so perhaps bugs are being fixed
> > in package installation support programs. You should be able
> > to see the symlinks being created in /var/log/apt/term.log*
> > if they haven't yet rotated away.
> 
> On the first machine:
> 
> Setting up dmeventd (2:1.02.185-2) ...
> Created symlink /etc/systemd/system/sockets.target.wants/dm-event.socket → /lib/systemd/system/dm-event.socket.
> Setting up lvm2 (2.03.16-2) ...
> Created symlink /etc/systemd/system/sysinit.target.wants/blk-availability.service → /lib/systemd/system/blk-availability.service.
> Created symlink /etc/systemd/system/sysinit.target.wants/lvm2-monitor.service → /lib/systemd/system/lvm2-monitor.service.
> Created symlink /etc/systemd/system/sysinit.target.wants/lvm2-lvmpolld.socket → /lib/systemd/system/lvm2-lvmpolld.socket.
> 
> On the second machine:
> 
> Setting up dmeventd (2:1.02.185-2) ...
> Created symlink /etc/systemd/system/sockets.target.wants/dm-event.socket → /usr/lib/systemd/system/dm-event.socket.
> Setting up lvm2 (2.03.16-2) ...
> Created symlink /etc/systemd/system/sysinit.target.wants/blk-availability.service → /usr/lib/systemd/system/blk-availability.service.
> Created symlink /etc/systemd/system/sysinit.target.wants/lvm2-monitor.service → /usr/lib/systemd/system/lvm2-monitor.service.
> Created symlink /etc/systemd/system/sysinit.target.wants/lvm2-lvmpolld.socket → /usr/lib/systemd/system/lvm2-lvmpolld.socket.
> 
> > Or else, have you run systemctl on dmeventd, in order to change its
> > status?
> 
> I'm not sure what to do.

I don't know anything about your machine, or the service provided by
these symlinks. But my own experience is that systemd is not bothered
about which of the two paths is the target, and renaming links with
ln -sf   doesn't affect running instances.

But for easing the task of comparing configurations, you could just
massage your listings so that any symlink targets listed as /lib…
appear as /usr/lib….

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#268814

FromDavid Wright <deblis@lionunicorn.co.uk>
Date2024-04-11 07:10 +0200
Message-ID<IrURb-5uWo-7@gated-at.bofh.it>
In reply to#268807
On Thu 11 Apr 2024 at 03:36:59 (+0200), Vincent Lefevre wrote:
> On 2024-04-10 09:52:51 -0400, Dan Purgert wrote:
> > I'd hazard it's a consequence of usrmerge being the "default state" in
> > one installation and not the other.
> 
> Both machines have always been usr-merged (i.e. from the Debian
> installation).

This is trixie, is it not, so perhaps bugs are being fixed
in package installation support programs. You should be able
to see the symlinks being created in /var/log/apt/term.log*
if they haven't yet rotated away. Or else, have you run
systemctl on dmeventd, in order to change its status?

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#268802

FromDavid Wright <deblis@lionunicorn.co.uk>
Date2024-04-10 16:30 +0200
Message-ID<IrH7z-5moG-7@gated-at.bofh.it>
In reply to#268799
On Wed 10 Apr 2024 at 12:33:21 (+0200), Vincent Lefevre wrote:
> On one machine, I have
> 
> lrwxrwxrwx 1 root root 35 2023-10-07 13:43:24 /etc/systemd/system/sockets.target.wants/dm-event.socket -> /lib/systemd/system/dm-event.socket
> 
> and on another one, I have
> 
> lrwxrwxrwx 1 root root 39 2024-01-05 16:54:09 /etc/systemd/system/sockets.target.wants/dm-event.socket -> /usr/lib/systemd/system/dm-event.socket
> 
> These symlinks were created at Debian installation time, and in
> both cases, the dmeventd version is 2:1.02.196-1+b1.
> 
> Shouldn't the system ensure that symlinks are consistent on different
> machines (even though the above symlinks are equivalent), for instance
> to ease the comparison of configurations between machines?
> 
> For instance, shouldn't usr-is-merged convert the symlinks to a
> canonical path?

No, that's the role of usrmerge. All usr-is-merged does is check
whether usr /is/ merged already and, if it isn't, report the fact
and fail to install. The only code in usr-is-merged is its preinst.

There's an FAQ in /usr/share/doc/usrmerge/README.Debian.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#268805

FromJeffrey Walton <noloader@gmail.com>
Date2024-04-10 21:00 +0200
Message-ID<IrLkR-5oON-3@gated-at.bofh.it>
In reply to#268799
On Wed, Apr 10, 2024 at 7:00 AM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> On one machine, I have
>
> lrwxrwxrwx 1 root root 35 2023-10-07 13:43:24 /etc/systemd/system/sockets.target.wants/dm-event.socket -> /lib/systemd/system/dm-event.socket
>
> and on another one, I have
>
> lrwxrwxrwx 1 root root 39 2024-01-05 16:54:09 /etc/systemd/system/sockets.target.wants/dm-event.socket -> /usr/lib/systemd/system/dm-event.socket
>
> These symlinks were created at Debian installation time, and in
> both cases, the dmeventd version is 2:1.02.196-1+b1.
>
> Shouldn't the system ensure that symlinks are consistent on different
> machines (even though the above symlinks are equivalent), for instance
> to ease the comparison of configurations between machines?
>
> For instance, shouldn't usr-is-merged convert the symlinks to a
> canonical path?

Be careful of fiddling with the Systemd symlinks. If you convert the
relative ones to absolute ones, then the machine will fail to boot.

Jeff

[toc] | [prev] | [next] | [standalone]

#268828

FromDavid Wright <deblis@lionunicorn.co.uk>
Date2024-04-12 21:10 +0200
Message-ID<IsurD-5QJk-5@gated-at.bofh.it>
In reply to#268805
On Wed 10 Apr 2024 at 14:36:20 (-0400), Jeffrey Walton wrote:
> On Wed, Apr 10, 2024 at 7:00 AM Vincent Lefevre <vincent@vinc17.net> wrote:
> >
> > On one machine, I have
> >
> > lrwxrwxrwx 1 root root 35 2023-10-07 13:43:24 /etc/systemd/system/sockets.target.wants/dm-event.socket -> /lib/systemd/system/dm-event.socket
> >
> > and on another one, I have
> >
> > lrwxrwxrwx 1 root root 39 2024-01-05 16:54:09 /etc/systemd/system/sockets.target.wants/dm-event.socket -> /usr/lib/systemd/system/dm-event.socket
> >
> > These symlinks were created at Debian installation time, and in
> > both cases, the dmeventd version is 2:1.02.196-1+b1.
> >
> > Shouldn't the system ensure that symlinks are consistent on different
> > machines (even though the above symlinks are equivalent), for instance
> > to ease the comparison of configurations between machines?
> >
> > For instance, shouldn't usr-is-merged convert the symlinks to a
> > canonical path?
> 
> Be careful of fiddling with the Systemd symlinks. If you convert the
> relative ones to absolute ones, then the machine will fail to boot.

I don't think there should be any relative systemd symlinks in
/etc/systemd/ unless, for some peculiar reason, you've hand-crafted
them yourself.

Cheers,
David.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web