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


Groups > linux.debian.bugs.dist > #1171206

Bug#1053677: base-files: /var/lock points to non-existing /run/lock

From Santiago Vila <sanvila@debian.org>
Newsgroups linux.debian.bugs.dist
Subject Bug#1053677: base-files: /var/lock points to non-existing /run/lock
Date 2023-10-09 01:40 +0200
Message-ID <HmLxn-eu8P-1@gated-at.bofh.it> (permalink)
References (1 earlier) <HmG4F-eqSJ-5@gated-at.bofh.it> <HmEvT-eq7h-1@gated-at.bofh.it> <HmKKZ-etEg-1@gated-at.bofh.it> <HmEvT-eq7h-1@gated-at.bofh.it> <HmKKZ-etEg-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


severity 1053677 normal
thanks

El 9/10/23 a las 0:34, Diederik de Haas escribió:
> I did initially wonder to which package to file the bug against as next to
> debootstrap I also considered to file it against aptitude.
> But as the base-files package creates the symlink, I think it's therefor also
> its responsibility to make sure it points to an existing directory.

I see your point, but the directory /run/lock is special, because
directory /run is usually a ramdisk. The base-files package may not be
responsible for creating it, because it would not survive a reboot.

According to Bug #1039979 (where I'm asked to make such symlink relative,
which I can't for now because it's against policy) such directory is
re-created by systemd if you accidentally remove it, but it's
considered "legacy".

This is a snippet from /usr/lib/tmpfiles.d/legacy.conf:

----------------------------------------------------------------------
# These files are considered legacy and are unnecessary on legacy-free
# systems.

L /var/lock - - - - ../run/lock
L /var/log/README - - - - ../../usr/share/doc/systemd/README.logs
----------------------------------------------------------------------

This suggests to me that any program trying to use /var/lock directly
instead of /run/lock is probably buggy and should be fixed.

Therefore I think you should report this (as a different bug)
against any package trying to use /var/lock directly.

As I said, I don't think we can make base-files responsible for the
existence of /run/lock. If this is a bug at all in base-files,
it would be to remove /var/lock altogether, but that's something
I would have to coordinate with systemd maintainers. I'm going
to keep this open for now until we know if we can do that or not.

Thanks.

Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Bug#1053677: base-files: /var/lock points to non-existing /run/lock Diederik de Haas <didi.debian@cknow.org> - 2023-10-08 18:10 +0200
  Bug#1053677: base-files: /var/lock points to non-existing /run/lock Santiago Vila <sanvila@debian.org> - 2023-10-08 19:50 +0200
    Bug#1053677: base-files: /var/lock points to non-existing /run/lock Diederik de Haas <didi.debian@cknow.org> - 2023-10-08 20:40 +0200
    Bug#1053677: base-files: /var/lock points to non-existing /run/lock Diederik de Haas <didi.debian@cknow.org> - 2023-10-09 00:50 +0200
      Bug#1053677: base-files: /var/lock points to non-existing /run/lock Santiago Vila <sanvila@debian.org> - 2023-10-09 01:40 +0200
        Bug#1053677: base-files: /var/lock points to non-existing /run/lock Diederik de Haas <didi.debian@cknow.org> - 2023-10-09 12:30 +0200
          Bug#1053677: base-files: /var/lock points to non-existing /run/lock Santiago Vila <sanvila@debian.org> - 2023-10-09 13:20 +0200
            Bug#1053677: base-files: /var/lock points to non-existing /run/lock Diederik de Haas <didi.debian@cknow.org> - 2023-10-12 00:00 +0200
              Bug#1053677: base-files: /var/lock points to non-existing /run/lock Santiago Vila <sanvila@debian.org> - 2023-10-16 00:00 +0200

csiph-web