On 25/11/2015 13:30, lee wrote: > walt <[email protected]> writes: > >> On Tue, 24 Nov 2015 23:39:01 +0100 >> lee <[email protected]> wrote: >> >>> >>> ... >> >> >>> Well, ok, the file is still locked. >>> >>> 'group-' looks like a backup, and 'group.lock' contains 10563, which >>> is the pid of groupadd. I'd think that's ok. >>> >>> So what all does it take to create a system group? I suppose I could >>> kill groupadd and the emerging might go on, though I wonder what the >>> problem might be and if something else besides making an entry to >>> /etc/group needs to be done. What might require an indefinite delay >>> here? >> >> Any unusual network activity? (DNS lookups that shouldn't be >> happening, etc.) > > There's nothing suspicious in the firewall log and no unexpected DNS > queries.
Ignore DNS, it has absolutely nothing to do with creating a group. A common human trait in dealing with problems with unknown causes is to start investigating all manner of weird and entirely unrelated things. I suppose theoretically you might discover some interaction between them in truly bizarre conditions but that's never something you entertain. Much like you don't check the health of your dog when investigating a flat type (protests about dogs biting tyres and getting stomach upsets notwithstanding) > The emerge before this one was apache, which I suppose also creates a > system group, and that worked just fine. > > I'll probably reboot today or tomorrow because I need to have a > differently configured kernel running to be able to do some traffic > shaping. If I do that, I'll probably just kill groupadd and see if the > merging continues. The group is already created so kill groupadd. One of three things will happen: 1. the emerge will continue. Do nothing 2. The emerge will fail with a groupadd error. Restart the emerge 3. Nothing will change. Kill the emerge and restart it If the lockfile persists after killing groupadd, delete it. -- Alan McKinnon [email protected]
