GNU bug report logs - #73494
[PATCH 0/2] tmpfs /run.

Previous Next

Full log

Message #71 received at 73494 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Hilton Chain <hako <at> ultrarare.space>
Cc: Vagrant Cascadian <vagrant <at> debian.org>, 73494 <at> debbugs.gnu.org
Subject: Re: mixup with tmpfs /run patch?
Date: Thu, 06 Mar 2025 09:15:23 +0900

Hi Hilton,

Hilton Chain <hako <at> ultrarare.space> writes:

[...]

>> +(define %runtime-variable-data
>> +  (file-system
>> +    (type "tmpfs")
>> +    (mount-point "/run")
>> +    (device "tmpfs")
>> +    (flags '(no-suid no-dev strict-atime))
>>               ^^^^^^^
>>
>> It might be worth re-testing with the no-suid part removed as originally
>> intended, as it might be breaking other things too... (e.g. if a service
>> relies on setuid bits or something?)

Good call!  That was me adding this last minute after inspecting how
/run is mounted on a Fedora VM, without giving much thought about our
own /run/privileged binaries, ah.

>> I looked forward to tmpfs /run that works! :)

Me too!

> I aimed at doing minimum work for this patch series, but we still need to
> consider what to do next.  I have thought about three options:
>
> 1. Change all references of /var/run to /run.
>
>   This will be a lot of work and will force all users who have touched the
>   change to update and reboot.
>
> 2. Keep existing references but change new packages / services.
>
>   We need to ensure new references are consistent for one package otherwise it
>   won't work on systems with separate /var/run and /run (older Guix System and
>   some foreign distros maybe), we can't find such issue easily either after
>   switching to unified /var/run and /run.

This could be necessary for some containerized services, I think.  For
example in jami-service-type, "/var/run/jami" is exposed to the
container.  I'm not sure how file-system-mapping handles that, but I
assume it doesn't resolve the link first so wouldn't actually share
/run/jami.

> 3. Don't change references, use what upstream uses.
>
>   Since we are currently using separate /var/run and /run, we don't have to deal
>   with any issue other than currently encountered ones for finishing this patch
>   series.
>
> I think I would go for 3, which requires less to no effort :) and is unlikely to
> introduce breakage.

I think 3., doing required minimum to get this working is the better
path forward; it's already tricky enough :-).

I'll try investigating why 'make check-system TESTS=jami' fails with
patch 2/2 of this series.  We should run all system tests and see if
there are other new failures too.

-- 
Thanks,
Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.