Opened 12 years ago
Closed 12 years ago
#1104 closed defect (fixed)
live session user does not belong to users group on low end hardware
| Reported by: | kalxas | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | OSGeoLive6.5 |
| Component: | OSGeoLive | Keywords: | |
| Cc: | live-demo@… |
Description
This occurs on my old netbook when I start GeoServer after boot. It seems that user is not added in users and www-data groups affecting many applications.
Reproduced by Hamish too:
"Starting geoserver on my old & slow Atom netbook I saw the same trouble with the user not belonging to the 'users' or 'www-data' groups. It's a race condition at boot time, the auto-login launches before rc.local has finished, and rc.local is what adds the user to those groups. It's weird though as all the other groups (audio, ..) are present. The only thing to be done is to log out and log back in, or start from a Terminal prompt and start a new login with 'su - user' then launch from there. Launching the startups as root doesn't help since then root owns ~/.mozilla etc. and you get locked out. If anything is done about it, the welcome message needs updating. Changing the auto-login sequence is a bit of a pain, IIRC, but worth looking into. I guess someone decided speed to the desktop was more important than having a working system at bootup... now what other OS does that remind me of..?"
Change History (11)
comment:1 by , 12 years ago
follow-up: 3 comment:2 by , 12 years ago
In that case the rc.local script should be made lighter to complete faster...
comment:3 by , 12 years ago
Replying to kalxas:
In that case the rc.local script should be made lighter to complete faster...
For one thing, that's not a very robust approach to fixing a race condition bug. For another, rc.local is already very light and put at the start of the rc2.d init.d scripts.
The mysql job is not in rc.local, it's in its own S99rc script, run last.
attempted fix for the group issue in r10010: try to add the groups as part of the live user creation scripts in casper.
https://help.ubuntu.com/community/LiveCDCustomization#Advanced_Customizations
Hamish
comment:5 by , 12 years ago
It seems that the fix is working for my netbook. I want to test on a full build before closing this one...
comment:6 by , 12 years ago
| Priority: | critical → major |
|---|
comment:7 by , 12 years ago
I'm booted into 10018 VM (no longer on the aiolos site), and I don't see 27osgeo_groups anywhere in /usr/share/initramfs-tools/scripts/casper-bottom/, and /var/boot/boot.log is roughly the same as before, with the first-to-be-added audio group being added just as the log ends, when now all groups should be added nearer to the top of that log.
?, Hamish
comment:8 by , 12 years ago
Hi,
tested 4gb usb install 10018 on fast i7 workstation: ok.
/var/log/boot.log shows groups being added in parallel with the log
tested 4gb usb install 10018 on 2008 Atom dual core netbook: fails.
/var/log/boot.log doesn't show any groups being added this time.
leaving it for a few minutes shouldn't make any difference: if the desktop session is spawned before the group is assigned, it's impossible for that to change later on*. That's not how unix inheritance | process sandboxing works. Only logging out and logging back in will help.
[*] without a new su - user login or newgrp run in a terminal (and then it only applies to things started by that terminal, it can't propagate to the parent or sibling processes)
Hamish
comment:10 by , 12 years ago
confirmed fixed in r10027 test-build by adding the group adding commands to the end of the casper live boot /usr/share/initramfs-tools/scripts/casper-bottom/25adduser startup script.
Hamish
comment:11 by , 12 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
confirmed fixed on build [10028]
Replying to kalxas:
They are added, just the live-user scripts don't wait for the init scripts to finish before they start logging in the user. And once the xfce session process is launched, there's no way to alter the groups it belongs to without a logout and back in.
rc.local is already first in line in /etc/rc2.d/ at S10, so we can't make it any earlier. A question remains if the live-user setup is doing something funny explicitly to those groups.
Hamish