11i boot: auto_parms[1589]: /tmp/sh##.###:

[Alan Turner]

Back from site installation, able to investigate a bit more.

re Tim's post 12:38 GMT on 27/08/03:
grep on netconf gave a single line:
INTERFACE_NAME[0]="lan0"

I edited debug into /sbin/auto-parms (I used /sbin/mount rather than bdf to test filesystems). See attachment auto.dbg

The error messages to screen were unchanged, and the debug showed that:
a)set_parms.util didn't run (PATH unchanged)
b)/tmp was on the root FS at this time
c)MountLocalFileSystems worked fine (and thereby hid /tmp on the root FS).

My conclusion is that the shell is wanting to create /tmp/sh76.113 to let it run set_parms.util, but is unable to create it (file already exists) and isn't running the script. This causes the other problems. Files linger in /tmp because MountLocalFileSystems stops them being deleted.

So, my next experiment is to delete files from /tmp before trying to source set_parms.util.

[Kent Ostby]

Alan -- I know that you've checked that we are past the /etc/rc.config area when we start getting these messages, but I'd really like to see output from a couple of commands if you could:


1) ll /etc/rc.config.d

2) ll /sbin/rc1.d

The reason I continue to bring up /etc/rc.config.d is that auto_parms is called out of /sbin/rc and I would like to be able to look at that list of files and ensure that we're good.

Also, I'm making an assumption that this problem started very recently (i.e. around the time of your initial post).

Best regards,

Kent M. Ostby

[Alan Turner]

Kent, listings as requested in the attachment, also a copy of my modified auto_parms which gets around the problem by pre-deleting /tmp.

There are a few scripts with execute permission in rc.config.d, but these are as set by the installation.

The problem isn't a recent one. I first noticed it 13/6/2003, for /tmp/sh81.113, on a different machine (more disks on different interfaces). I called HP (1201631958) and the advice was to chmod auto_parms from 544 to 444 - this was disastrous, so I reinstated the original permissions and deleted /tmp.

It surprises me that others haven't seen this - I'd have thought anyone with /tmp on a separate filesystem would see this on HP-UX 11i

[Steven Gillard_2]

Alan,

Actually, I am witnessing the same behaviour. In fact, if I just run ". /sbin/set_parms.utils" from my shell prompt, I'm left with 4 new temporary files in /var/tmp!

I haven't tried it yet, but I suspect this is related to the version of the POSIX shell we're running - there are a couple of fixes listed in the latest patch PHCO_28831 as follows:

10.sh-posix(1) leaves temporary files .

11.sh-posix(1) does not remove "here-documents".

I don't have this patch installed but I suspect it will fix the problem - you should give it a try if you can.

Regards,
Steve

[Steven Gillard_2]

Sorry thats an 11.0 patch, you want PHCO_27345 instead:

( SR:8606277532 CR:JAGae41602 )
sh-posix(1) with '-c' option, leaves temporary
files when here-document is used in functions.

This is the exact problem I experience on my system - the contents of the temporary files is the here-documents in the NotifyRoot function in set_parms.utils.

Regards,
Steve

[Kent Ostby]

Alan -- I note at least one .sh file in there.
I'm betting that moving it out will fix the problem.

The other ones I'm having you check are ones that I dont have on my system. They are probably perfectly fine.

Here are the commands I would suggest that you run:

cd /etc/rc.config.d
. ./horace_dbase_comms_config.sh
. ./Dmiconfig
. ./auditing
. ./eus
. ./kl
. ./pdcinfo
. ./scrdaemon
. ./slsd
. ./webadmin
. ./xf86

If ANY of these files returns anything other then the prompt, it should be moved out (I usually create a directory like /root/saveme and move them there).

I truly suspect that the horace_dbase_comms_config.sh being moved will do the trick.

its likely a script that should be put in /sbin/init.d and then linked to out of the /sbin stuff.

Best regards,

Kent M. Ostby

[Alan Turner]

Steve

Thanks for confirmation that I'm not the only one.

I couldn't try PHCO_28831 as it's an 11.00 patch and I'm running 11.11. However, the changes you listed are actually from the 27344 description, and I do have the 27345 11.11 POSIX shell (not clear if this is also /sbin/sh - the patch lists /usr/newconfig/sbin/sh, but not /sbin/sh). I think 27344 and 27345 are roughly equivalent (both are cited for Security Bulletin 275).

You're welcome to try my "fixed" auto_parms; of course, this would be wiped out by the next auto_parms patch.

[Steven Gillard_2]

You're right, /usr/newconfig/sbin/sh is the statically linked version of the shell. Its interesting that the patch doesn't put it in /sbin for you, maybe HP didn't test it with the startup scripts fully? There's no special instructions saying that this should be a manual step but it looks like it is.

I would suggest you try moving this version of the shell to /sbin/sh.new, then changing auto_parms to use it. Hopefully that will fix the problem.

And if you've still got that call open with HP ask them why /sbin/sh is not patched correctly when you install PHCO_27345... unless anyone else knows the answer?

Regards,
Steve

[Alan Turner]

Kent

None of the scripts you listed outputs anything. All other than horace_dbase_comms_config.sh are standard HPUX configuration scripts. The horace.... script is part of a meteorological data processing package; all it does is to define 4 environment variables.

I don't get the error messages now that I pre-delete /tmp/sh[0-9]*.[0-9]*, i.e. ensure that /tmp/sh76. can be created, thereby allowing /sbin/set_parms.util to run and set PATH properly.
However, this uses a locally-modified auto_parms script, so the fix is at risk until HP issues a formal fix for the problem.

Given that [I believe] there is a bug in HP-UX, how do I go about getting it fixed. Also, I don't know if this counts as a bug in the shell (requiring temporary files in /tmp) or in auto_parms (mounting a filesystem on /tmp and stopping the shell from housekeeping). Any suggestions?

[Kent Ostby · Accepted solution]

Alan --

Assuming you have an HP support contract, the way to get it fixed would be to log a call with HP and report the bug in your call.

A Response Center Engineer could then log your SR against HP-UX to be considered for a fix in the future.

Best regards,

Kent M. Ostby

[Alan Turner]

Steve

/sbin/sh is identical (cksum, also cmp -l)to /usr/newconfig/sbin/sh, i.e. I'm already using the new shell.

[Steven Gillard_2]

OK.. it must be moved into place by the configure script. I agree its definitely a bug - either auto_parms should mount all file systems itself before sourcing set_parms.utils, or the shell shouldn't create temporary files for here-documents when a function is sourced (I'd prefer the latter).

As Kent suggests log a call with the response centre and they can create a bug report. At least there's a simple work-around for the meantime.

Regards,
Steve