Stateful system directories

[Efraim Flashner <efraim@flashner.co.il>]

[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]

On Fri, Oct 18, 2019 at 05:08:20AM +0200, Ricardo Wurmus wrote:
> 
> Kei Kebreau <kkebreau@posteo.net> writes:
> 
> > Ricardo Wurmus <rekado@elephly.net> writes:
> >
> >> Kei Kebreau <kkebreau@posteo.net> writes:
> >>
<snip>
> >>
> >> Have you tried removing /var/lib/gdm and the contents of your user
> >> account’s .local/share/gnome* directories?
> >
<snip>
> 
> ~/.local/share/gnome-shell/application_state is a common problem.  It
> contains some state that different versions of GNOME seem to be choking
> on.  There are some other files like ~/.cache/gnome* that might affect
> GNOME and prevent starting after upgrades.  It’s frustrating.
> 
> /var/lib/gdm is the home directory of the gdm account, and it too can
> accumulate state.  In my opinion /var/lib/gdm should always be recreated
> on every boot.
> 

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))

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?

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]