Memory fault(coredump) after newgrp

[Henry Tu]

newgrp sometimes caused coredump and I can't find any
"core" file. But the problem only lasted for few minutes or
hours. Suddenly, the problem goes away and "newgrp" works normally again without any problems. It is very strange ! Can anyone help me ? Thanks !

OS:HP-UX 11i
PHCO_23083 installed.

Wu, S.-J.

[harry d brown jr]

Are you using "group" passwords?

Are you using "trusted"?

Are you using NIS, NIS+, and/or LDAP?

Do you have adequate number of users and user processes?

Enough Swap?

live free or die
harry

[Cheryl Griffin]

Find the core file, in the directory you executed newgrp, then execute:
# file core
# what core

This information will give you a place to start trouble shooting, for instance:
# file core
core: core file from 'find' - received SIGQUIT

I know this core was created from the find command and I can search the patch catalog for known issues or the Knowledge Base, Forums, internet for find and "received SIGQUIT" resolutions.

Cheryl

[Wodisch]

Ni Hao, Wu!

If the process used a "working" directory without write permission for the user running the process, then you won't get a "core" file, anyway!
And why using the old "newgrp" with all its problems? Maybe you can circumvent the need for it by "chgrp" then directory you want the files to be stored in to the grp you used with "newgrp", and set the SGID bit on that directory ("chmod g+s /that/dir"). Then all the files created in there will be owned by that group...

Just my $0.02,
Wodisch

[Martin Johnson]

When the problem occurs, check to see if /var is full. When /var fills up, a lot of strange problems can occur.

HTH
Marty

[Henry Tu]

Thank you for all the replies.

more clues to my problem...

1 login as user1
2 #newgrp grp2
3 memory fault and coredump
the messages should be..
"invalid/ineffective multibyte"
Memory fault(coredump)
4 user1 logout automatically(kick out by OS) and no core found

I am not sure about the exact
message in English. Since my
LANG=zh_TW.big5. And the error
message is in Chinese. When the problem occured. I change the LANG to C, then the problem disappeared. Change back to zh_TW.big5 then comes again. The weirdest thing is LANG=zh_TW.big5 works all the time. But caused coredump twice. One time lasted about 20 minutes, another lasted about 4 hours. During the above two periods. "newgrp" always caued a coredump. I called HP RC, they also can't identify that problem. Suddenly the problem disappeard. "newgrp" come back to normal.

Thank you for your patience. Sorry about my poor English.

To Harry,
==========

No NIS, NIS+, LDAP

No group password

"trusted"... Sorry, I don't know this.

my max. setting of users is 1024, procs is 8192. When the problems occured. The users and proceses are very low(20 users and about 1K processes)

The swap is OK. Only the pseudo-swap(memory) is used(40-50%). dev/vg00/lvol2 is still free.

To Cheryl,
==========
I test the newgrp command at home directory. No core can be found. I also find / -name core. Find nothing.

To Wodisch,
===========
There is one user, admuser who
can r/w all the files created/uploaded by a group of users. And all the users in
that group can't r/w each other's file. The admuser can not be root. I will try chgrp.
Thanks for your suggestion.
By the way, the working dir is home dir. No core found.

To Marty,
==========
/var only 30% used.

[doug hosking]

The reason you can't find the core file
is that newgrp is setuid root. For security
reasons, HP-UX doesn't generally create core files for programs more privileged than you
are, because that could let you see things in the core file that you shouldn't be allowed to see. (For example, contents of files with
restricted permissions/ACLs might be readable by setuid root programs but not by the user invoking them.)

[Henry Tu]

To Doug,

We also found that the newgrp
changes the coredummp(blocks)
from 4194303 to 0. There is
a patch for 11.0 but my OS is
11i. Thanks anyway.

Wu, S.-J.

[Michael Tully]

Hi,

The latest patch on 11i for 'newgrp' is PHCO_23083

Be sure to check for any dependencies should you go ahead and install this patch. Like any installation of a patch make sure that you create an ignite tape prior.

To create an ignite tape:

# /opt/ignite/bin/make_tape_recovery -x inc_entire=vg00 -I -v -a /dev/rmt/0mn

Regards
Michael

[Henry Tu]

Hi Michael,

Thanks for your reply.
Please note in the 1st article. PHCO_23083 already installed.

Wu, S.-J.