After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 701393 - treat secondary accounts better
treat secondary accounts better
Status: RESOLVED OBSOLETE
Product: gnome-initial-setup
Classification: Applications
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GNOME Initial Setup maintainer(s)
GNOME Initial Setup maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2013-05-31 21:12 UTC by Matthias Clasen
Modified: 2018-09-21 16:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
nonworking gnome-session patch (5.16 KB, patch)
2013-05-31 21:49 UTC, Matthias Clasen
none Details | Review

Description Matthias Clasen 2013-05-31 21:12:54 UTC
Currently, we simply autostart g-i-s in the user session, which is not quite what the designers had in mind. They'd like to have the same reduced shell mode that we use for the primary user, and only go to a full session when the user exists gnome-initial-setup. This should also allow to apply the language that was selected in g-i-s.

One possibility for this is to
a) have new a users session default to gnome-initial-setup
b) change the session to 'gnome' at the end of gnome-initial-setup
c) restart the user session when gnome-initial-setup is done

the api to restart the session could either be in gnome-session or in gdm
Comment 1 Matthias Clasen 2013-05-31 21:49:48 UTC
Created attachment 245783 [details] [review]
nonworking gnome-session patch

This patch is a quick attempt at adding a restart api to gnome-session. It doesn't quite work
Comment 2 Ray Strode [halfline] 2013-05-31 21:54:55 UTC
<mclasen> my quick attempt at adding org.gnome.SessionManager.Restart was not quite successful though
<mclasen> I tried to essentially do all the same as for logout, but when we quit the mainloop, reexec gnome-session instead
<mclasen> that seems to not quite work  because it won't restart the session bus
<mclasen> so many things don't get the hint that they should go away
<halfline_laptop> hmm
<halfline_laptop> well in practice it would be good enough for bug 701393 i bet anyway
<halfline_laptop> since there won't be anything running
<mclasen> I tried, I get the shell crashing and end up with a failwhale
<halfline_laptop> heh
<halfline_laptop> well one interesting point is we don't actually need to start the session bus manually these days
<mclasen> we still ship 00-start-message-bus.sh
<halfline_laptop> right and i think we still start it from main() in gnome-session too if it's not already started
<halfline_laptop> but dbus's autolaunching bus code is good enough now that we could probably drop the explicit starting
<halfline_laptop> though i guess that won't really help us
<halfline_laptop> because the session bus would still be tied to the display lifecycle
<halfline_laptop> unless we killed it ourself
<mclasen> anyway, I'll attach my quick attempt to that bug
<halfline_laptop> the problem with killing it ourselves now is i think it would bring down the whole session
<halfline_laptop> k
<halfline_laptop> though, i was just thinking it would bring down the whole session because of dbus-launch, but now that i think about it, that's not right
<halfline_laptop> it will only bring down the whole session because gnome-session exits when its bus connection goes away
<halfline_laptop> so maybe we're okay.  we just need to kill dbus-daemon before the reexec
<halfline_laptop> we'll also need to unset DBUS_SESSION_BUS_ADDRESS before the reexec
<halfline_laptop> we do have the gnome-keyring problem too though i suppose
<halfline_laptop> if it goes away during the reexec then the users keyring will get locked
<halfline_laptop> mclasen: so i guess i'm of the opinion now that we should do this at the gdm level
<mclasen> would seem cleaner
<halfline_laptop> we just never pam_close_session(), and instead fork() and exec again
Comment 3 Matthias Clasen 2013-06-01 03:02:57 UTC
<halfline_laptop> the problem with killing it ourselves now is i think it would bring down the whole session
<halfline_laptop> k
<halfline_laptop> though, i was just thinking it would bring down the whole session because of dbus-launch, but now that i think about it, that's not right
<halfline_laptop> it will only bring down the whole session because gnome-session exits when its bus connection goes away
<halfline_laptop> so maybe we're okay.  we just need to kill dbus-daemon before the reexec
<halfline_laptop> we'll also need to unset DBUS_SESSION_BUS_ADDRESS before the reexec
<halfline_laptop> we do have the gnome-keyring problem too though i suppose
<halfline_laptop> if it goes away during the reexec then the users keyring will get locked
<halfline_laptop> mclasen: so i guess i'm of the opinion now that we should do this at the gdm level
<mclasen> would seem cleaner
<halfline_laptop> we just never pam_close_session(), and instead fork() and exec again
Comment 4 Jasper St. Pierre (not reading bugmail) 2013-07-03 19:15:26 UTC
Is this still in progress?
Comment 5 GNOME Infrastructure Team 2018-09-21 16:09:43 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-initial-setup/issues/12.