Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 1453 - newgrp command produces segfault
Summary: newgrp command produces segfault
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Martin Schlemmer (RETIRED)
Depends on:
Reported: 2002-04-01 12:41 UTC by Karl Kedrovsky
Modified: 2006-02-04 07:06 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Karl Kedrovsky 2002-04-01 12:41:09 UTC
On a newly installed Gentoo 1.0 system the newgrp command produces 
a "Segmentation fault".  It's happening for all users/groups and forms of the 
command (i.e. "newgrp somegrp", "newgrp", "sg", etc. all fail).
Comment 1 Daniel Robbins (RETIRED) gentoo-dev 2002-04-03 23:20:04 UTC
Not happening here (I have an early 1.0 system up and running.)  Can you emerge
dev-util/strace and strace the command and see where it's dying and possibly why?
Comment 2 Karl Kedrovsky 2002-04-05 15:58:29 UTC
Here's the last 50 lines of the file produced by "strace -f -o strace.out newgrp":30792 munmap(0x40017000, 4096)          = 030792 brk(0x805e000)                    = 0x805e00030792 time([1018034418])                = 101803441830792 open("/etc/localtime", O_RDONLY)  = 330792 fstat64(3, {st_mode=S_IFREG|0644, st_size=1279, ...}) = 030792 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001700030792 read(3, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0"..., 4096) = 127930792 close(3)                          = 030792 munmap(0x40017000, 4096)          = 030792 getpid()                          = 3079230792 rt_sigaction(SIGPIPE, {0x40132544, [], 0x4000000}, {SIG_DFL}, 8) = 030792 socket(PF_UNIX, SOCK_DGRAM, 0)    = 330792 fcntl64(0x3, 0x2, 0x1, 0xffffffff) = 030792 connect(3, {sin_family=AF_UNIX, path="/dev/log"}, 16) = 030792 send(3, "<86>Apr  5 13:20:18 newgrp[30792"..., 71, 0) = 7130792 rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 030792 ioctl(0, 0x5401, {B38400 opost isig icanon echo ...}) = 030792 readlink("/proc/self/fd/0", "/dev/pts/1", 511) = 1030792 access("/var/run/utmpx", F_OK)    = -1 ENOENT (No such file or directory)30792 open("/var/run/utmp", O_RDWR)     = 430792 fcntl64(0x4, 0x1, 0, 0x4017e1e0)  = 030792 fcntl64(0x4, 0x2, 0x1, 0x4017e1e0) = 030792 _llseek(4, 0, [0], SEEK_SET)      = 030792 alarm(0)                          = 030792 rt_sigaction(SIGALRM, {0x4015eb40, [], 0x4000000}, {SIG_DFL}, 8) = 030792 alarm(1)                          = 030792 fcntl64(0x4, 0x7, 0xbffff680, 0xbffff680) = 030792 read(4, "\10\0\0\0\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 384) = 38430792 read(4, "\2\0\0\0\0\0\0\0~\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 384) = 38430792 read(4, "\1\0\0\0003N\0\0~\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 384) = 38430792 read(4, "\10\0\0\0\212\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 384) = 38430792 read(4, "\7\0\0\0~\10\0\0tty1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 384) = 38430792 read(4, "\6\0\0\0\177\10\0\0tty2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 384) = 38430792 read(4, "\6\0\0\0\200\10\0\0tty3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 384) = 38430792 read(4, "\6\0\0\0\201\10\0\0tty4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 384) = 38430792 read(4, "\6\0\0\0\202\10\0\0tty5\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 384) = 38430792 read(4, "\6\0\0\0\203\10\0\0tty6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 384) = 38430792 read(4, "\10\0\0\0\3528\0\0pts/4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 384) = 38430792 read(4, "\10\0\0\0\222%\0\0pts/5\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 384) = 38430792 read(4, "\7\0\0\0@Z\0\0pts/6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 384) = 38430792 read(4, "\10\0\0\0\233C\0\0pts/7\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 384) = 38430792 read(4, "\10\0\0\0\22H\0\0pts/8\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 384) = 38430792 read(4, "\10\0\0\0&H\0\0pts/9\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 384) = 38430792 read(4, "", 384)                  = 030792 fcntl64(0x4, 0x7, 0xbffff680, 0x401887c0) = 030792 rt_sigaction(SIGALRM, {SIG_DFL}, NULL, 8) = 030792 alarm(0)                          = 130792 close(4)                          = 030792 --- SIGSEGV (Segmentation fault) ---30792 +++ killed by SIGSEGV +++I have almost no idea what I'm looking at here but since the last thing it looked to me like it was doing was reading /var/run/utmp.  Having know idea what that is but finding a command called "utmpdump" I ran "utmpdump /var/run/utmp" and the output looked reasonable to me.  I can attach it if you'd like.  Oh, nuts.  I'm not sure what happened but the problem seemed to be solved by running the utmpdump command.  I'm not getting the segfault any more.  I'll keep the strace output from when the command was failing and the one I just produced from the command that now works.  If you want to see them let me know and I'll email them to you.  
Comment 3 Karl Kedrovsky 2002-04-10 08:54:07 UTC
I've had a chance to look into this a little more and I have a little more
information that may or may not help.

The bits in my last comment about utmpdump "fixing" the problem were obviously
bogus, the problem was showing up sometimes, other times the newgrp command
would work just fine.  Since reading the /var/run/utmp file was the last thing
the command did before seg faulting (according to strace) and it looked to me
that /var/run/utmp contained info about things in /dev I started looking to
that as the problem.  I checked my kernel config and noticed that I had 
support for Unix98 PTYs so I took that out and recompiled the kernel.  Now
the newgrp command fails every time when I'm using a terminal in X Windows.
Before that it would work sometimes in xterm or rxvt but never in konsole.  It
has ALWAYS worked on a virtual console.  I can also get the newgrp command to
work by doing a "ssh localhost" in konsole/xterm/rxvt reliably.  This all leads
me to believe that it related to the devices being used by the X terminals. ???

I hope this helps and if there is anything else I can do to help solve this
please let me know.
Comment 4 Seemant Kulleen (RETIRED) gentoo-dev 2002-04-15 00:41:04 UTC
Check your PAM settings -- it _may_ be related
Comment 5 Seemant Kulleen (RETIRED) gentoo-dev 2002-04-15 06:17:24 UTC
Az, sorry to push all this stuff on you :( I'll help you though.
Comment 6 Martin Schlemmer (RETIRED) gentoo-dev 2002-04-15 14:56:10 UTC
Do as root:

# ln -s /var/log/wtmpx /var/run/utmpx

not sure how "by the book" this fix is though.  An alternative,
is to create utmpx and wtmpx and reboot:

# >/var/run/utmpx
# touch /var/log/wtmpx

I havent tried this yet, as I am busy with a OO ebuild, and it takes
its time to build ;-)
Comment 7 Karl Kedrovsky 2002-04-16 07:32:32 UTC
I tried the "ln -s /var/log/wtmpx /var/run/utmpx" fix with no luck.  There is 
no /var/log/wtmpx on my system, don't know if that's a problem or not.  I tried 
creating both /var/run/utmpx and /var/log/wtmpx and rebooted but that didn't 
work either. I'm not sure if it's a problem but /etc/init.d/bootmisc 
removes /var/run/utmpx.

I also looked at my PAM settings as suggested by Seemant but I didn't find 
anything that I would consider odd.  I've never had the need to even look at my 
PAM settings so I'm not sure what to look for.  If someone has a suggestion as 
to anything specific I should check please let me know.
Comment 8 Martin Schlemmer (RETIRED) gentoo-dev 2002-04-16 15:53:09 UTC
My fault, should have been:

# ln -s /var/log/wtmp /var/run/utmpx
Comment 9 Martin Schlemmer (RETIRED) gentoo-dev 2002-04-25 15:17:57 UTC
The ln -s /var/log/wtmp /var/run/utpmx is a *very* BAD fix.  It breaks
much other things (w and who output, etc).
Comment 10 Karl Kedrovsky 2002-07-14 13:58:27 UTC
I just got back to needing newgrp again and checked to see if this was still an issue.  It worked worked like a charm so it looks like one of the many updates I've done over the last few months has fixed it.   
Comment 11 rabbitambulance 2006-02-04 07:06:47 UTC
It's a couple of years later, and I'm having this problem again:

zsh: 14454 segmentation fault  newgrp

All users, all shells. Dammit.