"nulptr dereferences trap enabled"

[Dennis Handly]

>"zombie master" is a term of your own creation to describe the parent PID of a zombie process?

That's correct, the term from folklore provides an identifiable name to the two modern computer science uses, spam (your second link) and bad UNIX programming.

[vmguy]

> bad unix programming.

I presume you're talking about dld.

Our code does not fail on any other unix platform. It is a standard unix technique to make mission critical software a daemon.

Patch PHSS_37947 is already in place, and the problem persists. We're stuck.

[Dennis Handly]

>I presume you're talking about dld.

No, we were talking about zombie masters and their lack of proper handling of SIGCHLD.

>It is a standard unix technique

I thought that caused the parent to exit so INIT is the parent? If so, there can't be zombies, just orphans.

>Patch PHSS_37947 is already in place, and the problem persists.

Are the checksums of the two /usr/lib/dld.sl the same?
If they are, you'll need to look at other patch differences.

At the top you mentioned 1603027519. If you are in contact with the Response Center, why are you asking questions here?

[vmguy]

> Why am I asking questions here

Good question. Why indeed is HP tech support blowing us off on an important issue.

I'm asking questions here because the HP channel is silent with resolutions.

Why are you asking? This is not fun.

[Dennis Handly]

>I'm asking questions here because the HP channel is silent with resolutions.

Did they mention the shutdown for two weeks may delay responses?

>Why are you asking?

I didn't want to waste time asking questions and making suggestions that they were already doing. And the first would be getting the patch level on the two machines the same.

[Laurent Menase]

Apparently you have a contract number problem and your call was closed.
If you have a software support contract escalate. -Support doesn't stop during holiday closure-

you can try to take a "tusc -p -E -o resfile pidofprocesses" from processes - parent and child processes-, started before the shutdown of the application.
It is possible that the parent process stay hang on some syscall on closure, causing SIGCLD to not be taken, leaving zombies

I like the "zombie master" I'll reuse it.

[vmguy]

Yes, we have tusc output. It all looks normal to me.

I'm involved with an escalation because no progress is being made for 2 months.

Sure, go ahead and use "Zombie Master", just make sure the listener understands what you're talking about. I wasted a bunch of time chasing a non-existent unix concept.

For 30 years, ppid has been sufficient to describe the condition. I thought it was rather innovative for HPUX to create a "zombie master" that orphans could cling to intead of init (ppid = 1).

Invent ... doesn't apply.

[Dennis Handly]

>PPID has been sufficient to describe the condition.

Where is the fun in that? :-)

>that orphans could cling to instead of init (ppid = 1)

That's still the case. When the zombie master is killed, init kills/reaps the orphaned zombies.

In any case, this is the secondary issue compared to finding out what patch is missing or broken. Have you compared the checksums for /usr/lib/dld.sl?

[Laurent Menase]

caseid 1603027519 looks like a short cut case.
so you probably have an other caseid.
Did they elevate to WTEC/L3 support?
Do you see the SIGCLD in the tusc output?
what syscall the parent process is hang on?
Is the parent process killable?
Did you get a crashinfo -l -s -v -t of the system when there are the zombies process to see what is the state of the parent process.

[vmguy]

Prior to server shutdown, ps output looks like this:

admin 20479 1 0 09:20:20 pts/0 00:04 /usr/local/../server64

After normal shutdown (no kill involved):

-3 20479 1 0 09:20:20 pts/0 00:07 /usr/local/../server64

The tusc output shows what I expect in a process shutdown:

munmap()
unlink()
lwp_detached_exit()
exit(0) <--- last entry in the log

I don't understand the comments about buggy application code related to waiting for SIGCHLD. The parent pid is init.

This is _very_ mature application code running on all flavors of unix and windows.