Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.bugs.dist > #1171206
| 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 |
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
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