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).
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?
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.
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.
Check your PAM settings -- it _may_ be related
Az, sorry to push all this stuff on you :( I'll help you though.
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 ;-)
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.
My fault, should have been: # ln -s /var/log/wtmp /var/run/utmpx
The ln -s /var/log/wtmp /var/run/utpmx is a *very* BAD fix. It breaks much other things (w and who output, etc).
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.
It's a couple of years later, and I'm having this problem again: newgrp zsh: 14454 segmentation fault newgrp All users, all shells. Dammit.
