Dear Maintainer,

/var/run is currently an absolute symlink to /run
/var/run should be a relative symlink to ../run
if /var/run is deleted, then /usr/lib/tmpfiles.d/var.conf recreates /var/run as relative symlink to ../run

/var/lock is currently an absolute symlink to /run/lock
/var/lock should be a relative symlink to ../run/lock
if /var/lock is deleted, then /usr/lib/tmpfiles.d/legacy.conf recreates /var/lock as a relative symlink to ../run/lock

Both of these symlinks are currently created in base-files postinst.

This is a problem because base-files currently deviates from the configuration files provided by debian in /usr/lib/tmpfiles.d/

Please fix.

Debian policy "9.1.1. File System Structure" https://www.debian.org/doc/debian-policy/ch-opersys.html#file-system-structure states:

"8. /var/run is required to be a symbolic link to /run, and /var/lock is required to be a symbolic link to /run/lock."

Additional clarification is provided in https://www.debian.org/doc/debian-policy/ch-files.html#id24

"This is necessary to allow top-level directories to be symlinks. If linking /var/run to /run were done with the relative symbolic link ../run, but /var were a symbolic link to /srv/disk1, the symbolic link would point to /srv/run rather than the intended target."

That part of the policy is certainly out of date with modern practices, where bind mounts and other solutions are commonplace and provide a much better solution to the described problem.

For this bugreport to be fixed, it would require changing those parts of debian policy.

However, the question is whether this is something against the letter of the policy but not against the spirit of the policy. My interpretation of the policy is that /var/run should end up pointing at the location of /run and it would be satisfied through relative symlinks too. Same for /var/lock

PS: making /var/run and /var/lock relative symlinks makes it much nicer and safer to work with chroots, avoiding the risk of damaging the real system's /run

It's also what archlinux does.

I attach a patch to change absolute symlinks to relative symlinks, which would fix this bugreport if you choose to do so.

which would fix this bugreport if you choose to do so.

At least the /var/run directory is also created as a symlink to ../run
by tmpfiles.d:

/usr/lib/tmpfiles.d/var.conf from the systemd package contains:
L /var/run - - - - ../run

There is also a proposal to update the debian policies regarding the
directory structure below /var:
https://lists.debian.org/debian-policy/2023/06/msg00016.html

Especially for read-only rootfs images with a dedicated (unpopulated)
/var partition, a solution using tmpfiles.d would be much appreciated.
But it is tricky to find out what is still missing as these directories
often get created in the postinstall scripts.

Best regards,
Felix Moessbauer

reassign 1039979 debian-policy
thanks

Dear Policy editors:

In this bug I'm asked to make /var/run and /var/lock symlinks
to be relative.

Maybe it's the right thing to do, but last time I tried to do that,
this is what happened:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690345

[ Summary: I had to revert the change because it was against policy ].

So, I'm reassigning this bug to debian-policy. Please drop me a note whenever
there is a consensus that relative symlinks are ok for /var/run and /var/lock
(even if there is not a new policy release reflecting it yet).

Thanks.

Why not fix /usr/lib/tmpfiles.d/var.conf to create the correct link then ?
/usr/lib/tmpfiles.d/var.conf is not policy-compliant as it is.

Cheers,

El 15/4/24 a las 22:26, Bill Allombert escribió:

However, the point the reporter was trying to make (if I understood correctly)
is that there is already a "trend" by which it's more useful to have those
symlinks as relative, and the systemd reference was just to highlight such trend.

So the question would be: Is policy really correct by requesting those
symlinks to be absolute considering that there seems to be a significant amount
of people (including systemd upstream) who consider more useful for them
to be relative?

Thanks.

This bug is a request to change the Policy requirement that /var/run and
/var/lock be absolute symlinks (to /run and /run/lock, respectively), and
instead be created as relative symlinks to ../run and ../run/lock. Debian
has attempted to make this change in initscripts and base-files before but
rolled it back because Policy requires symlinks that cross root file
system directories to be relative links.

The argument in favor of this proposal is that it makes working with
chroots easier. Specifically, if one is viewing or manipulating the
content of a chroot from outside the chroot, listing /chroot/var/run will
actually show the system /run, and creating files or directories in
/chroot/var/run will change system /run and have no effect on the chroot.
I agree that this is surprising and have run into this before.

Debian's current policy on this is intended to support relocation of file
systems using symlinks. Specifically, it was quite common back in the day
to discover that you failed to correctly anticipate file system needs when
partitioning the disk and now you have a running server that's about to
run out of space in /var. A common solution was to copy the contents of
/var to some other partition that had more free space (/home, say) and
then symlink /var to that partition. In this case, symlinks such as
/var/run must be absolute, not relative. If we used relative symlinks in
the above example, /var/run (actually /home/var/run), symlinked to ../run,
would resolve to /home/run, which doesn't exist, probably breaking the
system.

The counterargument to the current policy is that doing this with symlinks
is fairly obsolete and may well break other things these days (such as
some scenarios where the O_BENEATH flag is used). The preferred modern
approach would be to use a bind mount, which is invisible to path
resolution logic and would therefore work correctly with relative symlinks
as long as you encountered those symlinks via the /var path and not the
/home/var path.

After thinking this over for a while this morning, I think I personally
find the argument for a change persuasive, but I'm nervous about it
because it does break an (admittedly fairly old and arguably obsolete)
common sysadmin technique. Obviously, anything we change would only be for
new systems; we shouldn't change anything about existing systems that may
already be configured with symlinked file systems. Perhaps documentation
in the release notes would be sufficient to move forward with this change?

In short, I think symlinking file systems is no longer best practice, may
or may not be fully supported already (and probably isn't tested), and
therefore doesn't feel like it outweighs the clarity benefits for chroots,
but I'd like to get more feedback from others before we push forward with
proposing a change.

This feels like the sort of change that maybe we should discuss on
debian-devel if it feels like we have consensus here on the Policy list.

Le dimanche 8 février 2026, 20:36:32 heure normale d’Europe centrale Russ Allbery a écrit :

I think we should update and ask a debconf question during upgrade if we detect
/var being a symlink, that is the only problematic case, and upgrade if not the case during preinst

Moreover it will allow sysadmin possibility to bail out and use bind mount if we detect a symlink

And docker and so on
rouca

Le lundi 9 février 2026, 10:18:37 heure normale d’Europe centrale Bastien Roucaries a écrit :

Hi,

Here we could replace lock -> /run/lock by run/lock

In this case only one symlink should be handled

Bastien Roucaries <rouca@debian.org> writes:

Oh, this is a good point. I don't think we have to decide this in Policy
(we can leave it to Santiago to decide in base-files; I'm not sure if
there are special considerations for debconf prompting at that low of a
level in the package dependency tree), but I can see the merits in that
approach.

    Russ> This bug is a request to change the Policy requirement that
    Russ> /var/run and /var/lock be absolute symlinks (to /run and
    Russ> /run/lock, respectively), and instead be created as relative
    Russ> symlinks to ../run and ../run/lock. Debian has attempted to
    Russ> make this change in initscripts and base-files before but
    Russ> rolled it back because Policy requires symlinks that cross
    Russ> root file system directories to be relative links.


I have read your full analysis and I support the change with release
notes. I find the chroot behavior is more common these days than
filesystem relocation via symlinks.

Russ Allbery [08/Feb 11:36am -08] wrote:

Thanks for this.  Bind mounts are clearly better and have long been
supported, so I think it is okay to change this so long as we provide a
brief guide on using bind mounts for the same purpose in the release
notes.

I think if the maintainers of the packages in which the change would be
effected are on board, we don't need to do that.

For /var/run and /var/lock, I believe systemd already has those symlinks
as relative.

I also think it would be better to have them relative, and the main
reason I reassigned this from base-files to debian-policy is that I
wanted to avoid anybody telling me that I was violating policy by
doing the change on my own...

While we are at it, I wonder if we could actually deprecate those
locations for forky, and what would be the steps for doing so.

There is a small anomaly in the way base-files handles /var/lock
(see #1082498) and Helmut tells me that fixing the anomaly the right
way might require additional code similar to the one introduced in
base-files 13.3 for the usr-merge.

I don't have any hurry in fixing the anomaly, but maybe if we
deprecate /var/lock first, fixing the anomaly would be easier
(i.e. not requiring use-merge-grade machinery).

Thanks.

discourage its use but it continues to work indefinitely, or the one
where we plan to make it stop working? For /var/run, I think the first
would be fine but the second would not.

/var/run is required by FHS 3.0, and paths below /var/run are part of
interoperable cross-distro specifications from before /run was invented
(at least D-Bus, and probably others) so it's something that should
continue to exist essentially forever, similar to /bin -> usr/bin
continuing to exist after merged /usr so that /bin/sh still works. We
can discourage accessing it via that name and encourage accessing it via
/run (for example systemd already logs warnings if a systemd unit refers
to /var/run) but fully removing it would be an interoperability break,
not just between old Debian and new Debian but also between non-Debian
and new Debian.

I've requested that the next FHS version should require /run and
/var/run to be equivalent (in practice via a symlink or bind-mount or
similar), originally in
<https://web.archive.org/web/20250123180623if_/https://bugs.linuxfoundation.org/show_bug.cgi?id=1382>
and subsequently moved to
<https://gitlab.freedesktop.org/FHS/fhs-spec/-/issues/49>, and there
doesn't seem to have been any opposition to that.

I suspect there are similar considerations for /var/lock, but I don't
maintain anything that interacts with that directory, so I don't know
the finer details of its history and uses.

     smcv

I was actually thinking about actively encouraging everybody to do the
switch by dropping /var/run in unstable to see what breaks, but with
the intent of restoring it before forky becomes stable.

I believe we have done that sort of thing in the past (i.e. intentionally
breaking things in unstable in a reversible way), but I'm not sure if
this stragegy would be ok for /var/run at this point, or when it could be.

Thanks.

Please don't. I expect that the damage done in terms of programs not
starting or not working correctly would be completely disproportionate
to the cost of one symlink:
https://codesearch.debian.net/search?q=%2Fvar%2Frun&literal=1 currently
has 21291 results.

With upstream hat on, /var/run is mandated by the FHS, the interoperable
distro-independent location of the D-Bus system bus socket is
unix:path=/var/run/dbus/system_bus_socket, and the wording in the D-Bus
specification is carefully-chosen to allow (or even encourage) using
/run/dbus/system_bus_socket on systems like Debian where we know that
the two paths are equivalent. Making the two paths non-equivalent would
be a backward step, and I would prefer not to have to tell upstream
projects "sorry, yes, that's a weird Debianism and you'll have to work
around it" more than is strictly necessary.

Removing the symlink from base-files would also not have any effect on
systems that have systemd installed (because
/usr/lib/tmpfiles.d/var.conf creates it if necessary), so removing it
from base-files would be creating divergence between chroot/container
environments (schroot, podman, docker) and full-system environments with
systemd as init (lxc, systemd-nspawn, virtual machines, real hardware).

Similarly, it would not at all surprise me if there are chroot/container
managers that create /var/run -> ../run, if not already present, as part
of chroot/container startup, the same way we expect chroot/container
managers to be responsible for populating /dev, /proc and /sys. That
would partially mask the effect of dropping it from base-files.

     smcv

Le vendredi 20 février 2026, 12:22:38 heure normale d’Europe centrale Santiago Vila a écrit :

I think for /var/lock we could use dpkg-maintscript-helper dirtosymlink

The only condition is that the link should be relative to ./run/lock instead of /run/lock

rouca