This is a bug and it is serious, but there is a lot to discuss and explain here. I am breaking this report into three segments, the first will be the immediately fixable problem, the second will be a more detailed explanation of why, how, and possible solutions, and the third is a summary. ------- The Bug ------- Problem: Starting xfce on a read only system will result in xfce failing and/or taking a _very_ long time to initialize the desktop. Cause: Xfce (and perhaps xorg) try to write to a particular users home directory to place files, such as session data. Xfce wants to depend on these files. On a read-only system, these files do not get created and so a user cannot "startxfce4". Hack: I had written a hack that allowed me to continue despite this problem. (xfce4-session-4.4.2/xfce4-session/main.c, line 100), remove the exit. But it's a hack and not a fix. With the hack, I am able to continue into xfce, but the initialization is slow. I need to be able to get into xfce under a read only home directory. ----------- The Details ----------- Problem: XFCE is very handy to have for small (embedded) systems. In particular, this leads into running a system of a USB stick or other NAND, MMC, etc.. type devices. All of these have a flaw: limited number of writes, even with wear-leveling. The Flaw: Xfce seems to have a design flaw in this regard. There are places where Xfce performs write operations to the users home directories. As far as I can glance, this seems to be all over the place. On a magnetic disk that does not have limited writes, this is not a problem. Therefore, a quick solution or work around would be to boot a usb stick with read-only on and only mount r/w when explicitly needed. And so the said problem gets triggered. Possible Solutions: Compile in support for handling sessions when the session data cannot be written to the effective disk. Redesign how Xfce works in general to avoid writing to the effective disk as much as possible. - This can be implemented with a home directory config file option and/or a compile time option if avoiding these writes is not ideal for seemingly unlimited write systems. Allow for xfce to store the session data elsewhere (ie: /tmp/xfce4/username/session) which can be mounted as a tmpfs and will therefore _not_ be on the flash disk. - This also can be implemented with a home directory config and/or compile time option - I would prefer this last method as a user can then point this location back to their home directory and still use the default/current approach - Furthermore, a /home/username/xfcedata could be copied to /tmp/xfce4/username/data for startup and then on logout/shutdown/reboot have the files written back to the users home directory to preserve all changes made while reducing writes to a minimum. ------- Summary ------- Xfce is not safe to run on flash filesystems which are common in embedded environments. Allow for read-only home directories would result in a quick fix/workaround. The real problem can be fixed by implementing a hopefully end-user controlled option of defining where and how the home directory data is to be stored so that a single directory can be mounted tmpfs, allowing for a reduction of writes to the flash device.
What's wrong with the XDG_CONFIG_HOME and XDG_CONFIG_CACHE env vars? Are there other places where Xfce writes to your homedir without respecting these vars?
As far as I can tell, here are the directories created in the home directory: ~/.local/ ~/.config/ ~/.cache/ ~/.thumbnails/ Thunar's ~/.thumbnails/ and ~/.cache/ sound like they will have a considerable number of writes. Thanks for the env variables, I was not aware of their existence. Neither are currently defined on my system (should they be?), the only xfce'ish env variable I see defined is $XDG_DATA_DIRS. I will play with the environmental variables to see what kind of solution I can come up with. This, however, does not solve the session issue, which causes the read-only initialization bug. from the xfce4-session's main.c, line 96: /* check access to $HOME/.ICEauthority */ authfile = xfce_get_homefile (".ICEauthority", NULL); fd = open (authfile, O_RDWR | O_CREAT, 0600); That will attempt a write (or create) and fail on a read-only filesystem. Is there a way to specify an alternate .ICEauthority location? That is, without compiling the non-standard path in?
(In reply to comment #2) > As far as I can tell, here are the directories created in the home directory: > ~/.local/ Can be overridden with XDG_DATA_HOME. > ~/.config/ Can be overridden with XDG_CONFIG_HOME. > ~/.cache/ Can be overridden with XDG_CACHE_HOME. > ~/.thumbnails/ I don't think this can be overridden, but I imagine this will just quickly and silently fail on a r-o filesystem. Maybe the thumbnail spec has a way of overriding this too (I'm surprised these aren't stored under XDG_CACHE_HOME; maybe our implementation is old), but freedesktop.org appears to be down, so I can't check. > This, however, does not solve the session issue, which causes the read-only > initialization bug. > > from the xfce4-session's main.c, line 96: > /* check access to $HOME/.ICEauthority */ > authfile = xfce_get_homefile (".ICEauthority", NULL); > fd = open (authfile, O_RDWR | O_CREAT, 0600); > > That will attempt a write (or create) and fail on a read-only filesystem. > > Is there a way to specify an alternate .ICEauthority location? > That is, without compiling the non-standard path in? Not sure... probably requires a patch.
Hmm, maybe I'm missing something, but how about setting $HOME to somewhere on a tmpfs? That would perhaps require an initial copying of "skeleton" settings from the actual storage media into the tmpfs, but it would seemingly solve the problem...
For ~/.thumbnails and ~/.ICEauthority, you could also symlink them to somewhere else. Definitely would work for ~/.thumbnails, but not sure about ~/.ICEauthority.
Created attachment 2117 xfce4-session-4.4.3-respect_ICEAUTHORITY-1.patch It turns out the xorg's libICE respects the parameter ICEAUTHORITY. So a user can actually specify: export ICEAUTHORITY=/tmp/someuser/myice However, xfce currently doesn't respect this flag. I made a simple patch that does this for xfce4-session. The patch will default to the original behavior if ICEAUTHORITY is not defined and so this patch should be compatible and non-interfering.
Created attachment 2118 xfce4-session-4.4.3-respect_ICEAUTHORITY-2.patch apparently the g_getenv returns a static pointer and the g_free(authfile) will fail. This adds a check to control when and when not to run g_free(authfile)
Created attachment 2191 xfce4-session-4.4.3-respect_ICEAUTHORITY-3.patch Looks like I managed to screw up this very simple patch, yet again. This one is tested.
What's wrong with your earlier patch? I already committed a (different) fix for this a while ago, sorry, I must have forgotten to close this bug: http://svn.xfce.org/index.cgi/xfce/xfce4-session/trunk/xfce4-session/main.c?r1=28615&r2=29384 If that doesn't work, please reopen. (I hope it works, because xfce4-session was just tagged for the 4.6.0 release an hour or so ago.)