Opened 6 years ago

Closed 6 years ago

#1104 closed defect (fixed)

live session user does not belong to users group on low end hardware

Reported by: kalxas Owned by: live-demo@…
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 in reply to:  description Changed 6 years ago by hamish

Replying to kalxas:

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.

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

comment:2 Changed 6 years ago by kalxas

In that case the rc.local script should be made lighter to complete faster...

comment:3 in reply to:  2 Changed 6 years ago by hamish

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:4 Changed 6 years ago by kalxas

fix committed in [10010]

comment:5 Changed 6 years ago by kalxas

It seems that the fix is working for my netbook. I want to test on a full build before closing this one...

comment:6 Changed 6 years ago by kalxas

Priority: criticalmajor

I tested against the last build [10018] and when I leave my netbook rest before launching GeoServer? it works fine.

comment:7 Changed 6 years ago by hamish

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 Changed 6 years ago by hamish

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:9 Changed 6 years ago by kalxas

I cannot explain why my netbook is now working if the fix failed.

comment:10 Changed 6 years ago by hamish

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 Changed 6 years ago by kalxas

Resolution: fixed
Status: newclosed

confirmed fixed on build [10028]

Note: See TracTickets for help on using tickets.