1. Forum
  2. Usenet
  3. LINUX.DEBIAN.USER

  • inconsistency in the symlinks under /etc/systemd

    From Vincent Lefevre@21:1/5 to All on Wed Apr 10 13:10:01 2024
    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 <[email protected]> - 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)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Purgert@21:1/5 to Vincent Lefevre on Wed Apr 10 16:20:01 2024
    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

    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmYWma8ACgkQbWVw5Uzn KGCPiBAAuk//Ou0lahiBaXe7dBfpwEenU1Z9Xf9NqVLT+FmNvDLdPFpRIWnH7fob P086wi+rBOU9PzmeoIml4uzw6uyzRgarQcrbeOmaqKn0u7HqlsHGipTTBntvIjiM 1BPABLI8JNIl7l1/sdeKEbwpaonjl9aDV2iSrz+T8yTPu0/wFmSxWjgpluXwmTND PdsTAOKq25e8fxx+aOlzOrj77pJAQLmoQzqBwv7tL2ecGYSYgWmhBC7oqck0wrZt HBCfz0cfLWJTSgN5CP/0cdEhV9BfdRnubNR0I8zpHNcnuLyRD0mvUbLomChD9Bov gtha7dpBhJP/ppjJ1YEUIaenReOpK6YfTBt99cKMUOU/ZrSbDerjWvdiqEEvO2Ec PI4+kbwrPmW0L0RNWllPCcsByU+WQyR6WMjPJKdh1Fh5tHQYIceRxXunqye8TC/4 dgk5UWmsHzULv427pCMD+08tkuYOAYXiw0Ws6SUONra+6IkEbg/GaI4DWGTk43rj gtZ7ceeV1/VviqECX+z497HdE1CUz0cWR9TTgGbYtJ6uFFKSY6u6xybEaFNOe7ri 07ih4hV1d27gjybDEa6ZQWgkFircd2lndaOvfVBp58/pWVftRFNf2Pp75410OqEg pH5p/90zbJfHUWtJXpmy5aq0Wf7FkyZ4zGSOPBQFoazUO+pVWJY=
    =P1RB
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Us
  • From David Wright@21:1/5 to Vincent Lefevre on Wed Apr 10 16:30:01 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Vincent Lefevre@21:1/5 to Dan Purgert on Thu Apr 11 04:10:01 2024
    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 <[email protected]> - 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)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Wright@21:1/5 to Vincent Lefevre on Thu Apr 11 07:10:01 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Vincent Lefevre@21:1/5 to David Wright on Thu Apr 11 19:50:01 2024
    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 <[email protected]> - 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)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Wright@21:1/5 to Jeffrey Walton on Fri Apr 12 21:10:01 2024
    On Wed 10 Apr 2024 at 14:36:20 (-0400), Jeffrey Walton wrote:
    On Wed, Apr 10, 2024 at 7:00 AM Vincent Lefevre <[email protected]> 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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Wright@21:1/5 to Vincent Lefevre on Fri Apr 12 21:10:01 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)