[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Stateful system directories
From: |
Efraim Flashner |
Subject: |
Stateful system directories |
Date: |
Fri, 18 Oct 2019 10:35:01 +0300 |
User-agent: |
Mutt/1.12.2 (2019-09-21) |
On Fri, Oct 18, 2019 at 05:08:20AM +0200, Ricardo Wurmus wrote:
>
> Kei Kebreau <address@hidden> writes:
>
> > Ricardo Wurmus <address@hidden> writes:
> >
> >> Kei Kebreau <address@hidden> 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 <address@hidden> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
signature.asc
Description: PGP signature
- Stateful system directories,
Efraim Flashner <=