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

[Alan Turner]

Has anyone seen (and possibly resolved) this problem with booting on 11i?
Initially all goes well, then after several reboots, I get the following error msgs
just after the msg saying DHCP access is disabled:

/sbin/auto_parms[1589]: /tmp/sh76.113: cannot create
/sbin/auto_parms[8]: who: not found
/sbin/auto_parms[17]: ps: not found
/sbin/auto_parms[17]: grep: not found

Line 1589 of auto_parms is where it sources /sbin/set_parms.util, but I didn't
see anything like /tmp/$$. in there.
Lines 8 and 17 of auto_parms do not make sense, but lines 8 and 17 of the
CheckRunLevel function in auto_parms do use who, ps and grep to try and
find out if we're running from boot. The output in /etc/auto_parms.log suggest
this check fails, because the log says execution was stopped.
If I look at /tmp in single user mode before the real /tmp filesystem is mounted
I can see 128 files of the form sh.. They come in blocks
of 4, looks like they hold messages. I can see /tmp/sh76.113 (and .114, .115,
.116).
Apart from the "cannot create" / "not found" messages, my system seems to come up OK. Also, if I clear the /tmp directory in the root FS, the problem goes away for several boots.
I tried a call to HP a while ago - but not resolved so i thought I'd try the foru

[Chris Wilshaw]

The errors below indicate a number of problems

sbin/auto_parms[1589]: /tmp/sh76.113: cannot create
/sbin/auto_parms[8]: who: not found
/sbin/auto_parms[17]: ps: not found
/sbin/auto_parms[17]: grep: not found


The cannont create error could be for one of 2 likely reasons;

1) There is no free space

2) There is a permissions problem with either the /tmp directory, or a file/directory called sh76.113 beneath it.

The "not found" errors show that the script that is running is trying to pick up these commands from a location (probably /usr/bin), which is not mounted as a filesystem when the script runs.

[Tim Adamson_1]

You will find it is caused by the fact that /usr has not been mounted yet. I bet the messages occur prior to the start sequence where all the /sbin/rc.?/* scripts are run.

However, I don't have a solution for you. You will need to determine which of the scripts in /sbin/init.d is causing the problem.

I will need a little more thought on this problem.


Tim

[Tim Adamson_1]

Had another idea. Check to make sure that the files in /sbin/rc?.d are all sym links to files in /sbin/init.d.

Next go through the scripts in /sbin/init.d and look for those commands - who, grep, etc.

This way you should identify the scripts that are causing the problems.

It looks as though the system is sourcing the files in /sbin/init.d before executing them and because /usr is not mounted the who and grep fail as they live in /usr/bin (and most likely / is mounted as read only at this stage of the boot process hence the /tmp files can't be created).

Now more thought is required. Just thinking out loud.


Tim.

[Alan Turner]

Chris / Tim -thanks for your responses.
There's plenty of space on the root filesystem, which is where the /tmp/sh76.113 file exists (there's also loads of free space in the /tmp
filesystem). Permissions on /tmp/sh76.113 allow root to have write. As I have
/tmp/sh76.1 --> /tmp/sh76.116 in the /tmp directory, what I suspect is
happening is a crude "create workfile" loop, which tries to make a new file
/tmp/sh$$. and keeps incrementing to look for a file
which does not already exist - baling out at sh76.113 looks like a safetry
measure to stop an endless loop (interestingly, when I raised the HP call, the error file was /tmp/sh81.113). Possibly there's a subsequent "tidy up" of
/tmp, which hypothetically fails because by now the filesystem has mounted
on /tmp.
As for "who", "ps" and "grep" - yes, I would expect these to be in /usr/bin.
Given that auto_parms normally works, what I think has happened is that
/usr/bin ought to have been monted by this stage, but the earlier failure may
have stopped the mount occurring, or alternatively, may have stopped /usr/bin
being added to PATH.
I suspect all would work fine if I didn't have a separate filesystem for /tmp.
I do have an ls and tar archive of /tmp on the root filesystem, but I'm not sure they'd be helpful

[Kent Ostby]

Tim is right about the /usr not being mounted as the cause.

To find the script giving the error, go into /etc/rc.config.d and do the following:

ll -t | head -20

to get a list of the most recently changed files in this directory.

There should be NO scripts in this directory at all.

Starting at the top of the list, type:

. ./filename

Any file that kicks out messages when you do this should not be in this directory.

This directory is used for files that should be SOURCED not RUN so if a script was put in here, it needs to be moved.

[Alan Turner]

Tim (response #2) - the rc#.d scripts are symbolic links to init.d scripts, but
the who/ps/grep errors are from auto_parms, and are before the rc.utils script runs and draws the tabular boot display - so I need to hit CTRL-S at just the
right time or I can't see the error messages. The root FS is writable at the
stage of the errors, on the basis that if i dleete the files from the /tmp
directory, they get created and the errors stop (till slots 113 - 116 are used up
in the hypothetical temp file name schem

[Tim Adamson_1]

Hi Alan,

I might not have been clear before. Apologies if that is the case.

I am trying to picture where in the boot process this is occuring. Obviously the kernel is loaded. The auto_parms message normally occurs just before where the system lists everything as OK or FAIL or N/A as it runs through the /sbin/rc?.d directories.

If I am right in that assumption, then the filesystems have NOT been mounted, hence /usr is not mounted.

Also, / is mounted read-only first and then re-mounted later on. The message about not being able to create the /tmp/sh##.### file could be caused by the fact that root is still mounted as read only at this stage of the boot process.


Hope I have been clearer.


Tim

[Alan Turner]

Kent - I'm pretty sure that the who, ps and grep messages are coming from
the CheckRunLevel shell function in /sbin/auto_parms - line 8 of this
function does a "who", and line 17 of the function pipes "ps" through "grep"
and "awk", looking to see if auto_parms is running under /sbin/rc. I don't
get a "not found" for awk, but awk is in /sbin.
rc/config.d just holds files to be sourced - anyway, the problem goes away
if I remove the contents of /tmp on the root flesystem, but this isn't a nice
solution because I can't do it once the system has booted, as I can't umount
/tmp

[Alan Turner]

Tim
The error occurs just after the message

"/sbin/auto_parms: DHCP access is disabled (see /etc/uato_parms.log)"

i.e. just before the OK / N/A / FAIL tabular display (if I hit CTRL-S to see the
error messages, then press CTRL-Q, I get an error message from /sbin/rc
saying it couldn't read row and column information, and I lose the paged
version of the boot table - comes up as a scrolled list.

I believe the root FS has been remounted read/write at the time of the errors,
because new files are created if I clear out /tmp, also the DHCP access msg
refers to /etc/auto_parms.log, suggesting the /etc/auto_parms.log was written

I haven't been able to check if /usr is mounted at this stage, and I'm wary of
tweaking auto_parms to look, but I actually would expect /usr to be mounted
at this stage, otherwise why do I NOT get the "not found" messages from
auto_parms when I've cleared out /tmp (and, why would auto-parms have
"who", "ps" and "grep" in it if /usr is not meant to be mounted when
auto_parms runs, yet autopamrs is meant only to be run by /sbin/rc)