GNOME Bugzilla – Bug 767172
docs: Move GIO_USE_VFS to "okay for production" section
Last modified: 2016-06-03 01:24:19 UTC
Lots of projects like NetworkManager, ostree, udisks, soon polkit, etc. do this or *should* do this. And we need to support that forever.
Created attachment 328981 [details] [review] docs: Move GIO_USE_VFS to "okay for production" section
note, as a weird coincidence, i just pushed this change to accountsservice yesterday: https://cgit.freedesktop.org/accountsservice/commit/?id=87bf44fe091bdf446aa00e052dd10418a379a1a6
Review of attachment 328981 [details] [review]: looks fine to me
Wouldn't it be better to make a real API for this? Are the different apps even all disabling gvfs for the same reason? Are they all disabling it for reasons that are relevant to the current code, or are some of them disabling it to work around long-since-fixed glib/gvfs bugs?
> accountsservice doesn't need support for GVFS modules, > and those modules lead to /root/.cache getting created > at startup. > > accountsservice runs as root, but shouldn't be touching /root. Maybe gvfs just shouldn't create $HOME/.cache unless it needs it? (And there's certainly no guarantee that some other glib API isn't going to start touching files in $HOME later anyway.)
I agree a real api would be better than an environment variable hands down. I can't come up with a plausible reason any of the programs listed in comment 0 or comment 1 would want gvfs though. AccountsService was done specifically because initializing gvfs when not run in a session has the side effect of creating /root/.cache and that generated AVC log entries.
(midair collision)
Right, a lot of "desktop stuff" wants a "session" which implies a few things like a home directory, a session dbus. Neither of those exist (normally) for system services.
Attachment 328981 [details] pushed as 424b3b9 - docs: Move GIO_USE_VFS to "okay for production" section
(In reply to Colin Walters from comment #8) > Right, a lot of "desktop stuff" wants a "session" which implies a few things > like a home directory, a session dbus. Neither of those exist (normally) > for system services. So they all want GSETTINGS_BACKEND=memory too, right? (Otherwise if they open a TCP connection, they'll end up trying to spawn dconf-service because of GSocketClient -> GProxyResolver -> GSettings.)
(In reply to Dan Winship from comment #10) > (In reply to Colin Walters from comment #8) > > Right, a lot of "desktop stuff" wants a "session" which implies a few things > > like a home directory, a session dbus. Neither of those exist (normally) > > for system services. > > So they all want GSETTINGS_BACKEND=memory too, right? (Otherwise if they > open a TCP connection, they'll end up trying to spawn dconf-service because > of GSocketClient -> GProxyResolver -> GSettings.) Yeah. It's tempting to turn that on automatically if GIO_USE_VFS=local && getuid () == 0 or something. Or alternatively, detect somehow we're under a systemd unit.
Well, that's what I was saying about having a real API. We should figure out exactly what behavior it is that these programs want ("don't run D-Bus-based extension points"? "don't ever try to connect to the D-Bus session bus"?), and make an API that gives them that (and will be extended to do the same with future extension points as well, etc).
No disagreement here, but it seems like a separate bug from fixing the documentation to reflect reality (this one). https://bugzilla.gnome.org/show_bug.cgi?id=767183