Howdy! Efraim Flashner <[email protected]> skribis:
> On Sat, Oct 19, 2019 at 11:08:57PM +0200, Ludovic Courtès wrote: >> Hello Efraim, >> >> Efraim Flashner <[email protected]> skribis: >> >> > Ignoring the directories in users' home directories, /var/lib/gdm has >> > been a source of pain on GNOME upgrades, and we still have some problems >> > with /var/cache/fontconfig and I believe there is something else with >> > permissions if you switch between ntp and openntpd. I actually have the >> > following snippet in my OS-config: >> > >> > ;; This directory shouldn't exist >> > (file-system >> > (device "none") >> > (mount-point "/var/cache/fontconfig") >> > (type "tmpfs") >> > (flags '(read-only)) >> > (check? #f)) >> >> I think that would work, or we could even make it a writable tmpfs? > > I got angry with it and wanted to see if I could generate any error > messages. :) So far nothing. Of course there isn't a compelling reason > to really make it read-only if we recreate it each time, and it should > cut down on bugs for other directories. Yup, let’s do that. >> (Somehow, I do have /var/cache/fontconfig, but never hard any problems >> with it. It hasn’t been written to in months, and it’s only writable by >> root anyway. Does that mean that people run into problem when they run >> GUIs as root?) > > I have it too, not sure from what. I'm guessing some of the packages > which have fontconfig as an input get a dbus-something to create the > directory if it's missing. Heh, these dbus things doing stuff behind our back. :-) >> > While we work on fixing these does it make sense to modify some of these >> > services to unconditionally recreate their home directories on >> > boot/activation? >> >> Like /var/lib/gdm? Maybe. Or maybe ‘gdm-service-type’ could extend >> ‘file-system-service-type’ with a tmpfs for /var/lib/gdm? >> > > Sounds like a good idea. Would that also cause the directory to be > removed if gdm is removed? It should create a tmpfs and mount it over an > existing /var/lib/gdm, right? Yes. So the directory won’t be removed if gdm is removed, but that’s fine, it’ll just be an empty directory sitting there. >> I suppose that might increase startup time a bit since it’d be >> rebuilding its cache every time. Perhaps we’d also lose bits of state, >> no? > > The increase in startup time should be negligible, and according to > rekado, who seems to run into GDM issues the most, removing /var/lib/gdm > is one of the first steps when upgrading gnome or debugging gdm issues. Yeah, it’s a tradeoff, but we should try it on the bare metal to get a feel. There’s quite a bit of data in there that we’d be recreating at each boot: --8<---------------cut here---------------start------------->8--- $ sudo ls -l /var/lib/gdm/.cache totalo 16 drwxr-xr-x 2 gdm gdm 4096 Sep 19 08:45 fontconfig drwxr-xr-x 3 gdm gdm 4096 Apr 11 2019 ibus drwx------ 2 gdm gdm 4096 Apr 1 2019 libgweather drwxr-xr-x 97 gdm gdm 4096 Sep 19 08:45 mesa_shader_cache --8<---------------cut here---------------end--------------->8--- If you give it a spin, let us know how it goes! Ludo’.
