Subject: Re: mixup with tmpfs /run patch?

From: Maxim Cournoyer <[email-masked]>
Date: Thu, 06 Mar 2025 09:15:23 +0900

Hi Hilton,

Hilton Chain <[email-masked]> 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