"Slow" Shutdown/Startup Console on N-Class/rp7400... Endless "dots"...

[Alzhy]

Is there a fix to this?

I am sure my GSP is set to VT100 as do my Terminal Connection to my Console management system (Amity) but whenever I start or shut down this system ... instead of getting the orderly messages identifyin its stage of the startup or shutdown , I get very long dots and then the normal message.... And this is really slowing the startup/shutdown of the system down..


Appropriate points will be assigned...

Thanks!

[Pete Randall]

Nelson,

I'm sure you've already checked, but - anything in /etc/rc.log?


Pete

[Pete Randall]

Nelson,

Actually, make that /etc/rc.log.old.


Pete

[Alzhy]

Nothing out of the ordinary there Pete...

[Pete Randall]

Name resolution OK? I'm grasping at straws here because I can't think of a likely reason for this.


Pete

[IT_2007]

Do you get long dots for each startup/shutdown stage or only some of them?

Check which process takes long time to terminate from /etc/rc.log.old

[Alzhy]

Each one of them.. i.e.

Starting ServiceX.......................................................................................................................................................................................... several screenfulls.................................................................................................................................OK

Then goes on to the next...

Pretty strange isn't it?

[IT_2007]

Is it really bringing up service takes so long? How long does it take to come all the way up to level 3?

[Mel Burslan]

I am going to suggest one crazy thing here. Go into one of the long taking start scripts in /sbin/init.d and put a set -x on top or close to top, and see when it is the turn of this script, what you get on the screen. I Have a gut feeling about a network disconnect of some sort and wait is for the timeout of the connection, but again just a gut feeling.

[Bill Hassell]

Are you saying that *every* startup script has the long row of dots? If so, then the cause is your terminal. As the system boots up, the very first task is to identify the terminal -- which you do not have. Instead, you have an imitation, an emulator. But there are some AWFUL emulators out there, all claiming to be vt100 (or vt220, etc) compatible.

The fastest way to verify the problem is to use a 'real' terminal or a PC with Hyperterminal. If all goes well, then the problem is with the console path. Start by verifying that the console management box does *NOT* trap or interfere with any escape codes. This may require some persistent digging to discover. Most console servers (Avocent, Cyclades, Digi International, Lantronix, Logical Solutions, MRV Communications, Raritan) have a transparent interface with options to handle Sun/Solaris break problems and other features.

The terminal for startup is queried in the /sbin/rc.utils script (look for ttytype) and this is likely where the problem started. In that script, the 3 very important values are decoded: TERM ROWS COLUMNS. However, the introduction of the GSP for new machines created a very nasty feature: it interferes with terminal emulation. I was never able to find out why this design exists (the GSP is a dumb ASCII interface) but what happens is the setting for vt100 or hpterm in the GSP *DISABLES* terminal ID queries. The two terminal query programs tset and ttytype were changed so that whatever the GSP says, that is the terminal -- regardless of what you are actually using.

So here's the problem: whatever emulator you are using may not match the GSP setting. For instance, a (bad) emulator will allow 132 columns for the vt100 setting. While this is impossible for a 'real' DEC VT100 terminal, code writers can get far too clever. So the terminal doesn't match what the HP-UX code is expecting.

So after this long explanation, the fix is likely going to require a different emulator. You can test this online by changing your emulator to Wyse or HP or even VT220 and then running ttytype -s to see what it reports. A real query will report the new emulation but the console connection won't change because ttytype is hardcoded to read the GSP setting.

[Matti_Kurkela]

There might be a simpler explanation than the one offered by Bill Hassell. It is possible this is not really related to terminal type at all.

The HP-UX startup/shutdown scripts can be executed in several modes.

The most trivial mode is of course when the checklist function is turned off. By default this is never used.

"Screen mode" is used by default when the console understands HP-native control codes, i.e. whenever the console is a real HP terminal in native mode or an emulation of one. This produces a nice paged checklist of tasks with a title, and even colours the OK / FAIL messages if the terminal supports that.
To make that happen, the scripts in /sbin/rc?.d are actually run twice: once with argument "start_msg" or "stop_msg" to create the checklist, then a second time with argument "start" or "stop" to actually make things happen.

"Line mode" is used by default if the console is anything other than a HP terminal. This mode also collects the descriptions in advance, although this is not immediately obvious. When producing the messages, it chooses the number of dots so that each line will be of equal length.

And here's the problem: if you have even a single startup/shutdown script which emits a long message when called with argument "start_msg" or "stop_msg", it will cause the line mode to output dots for each checklist item so that they are as long as that one long message.

To find the cause of the problem, go through your /sbin/rc?.d directories and run each script you find using arguments "start_msg" and "stop_msg" in turn. For example, when you get to the script /sbin/rc3.d/S100nfs.server,
run the following commands:
/sbin/rc3.d/S100nfs.server start_msg
/sbin/rc3.d/S100nfs.server stop_msg

Generally, you should not need to be root to run this, unless some customized scripts are installed to be only readable by root.

Actually it is recommended to *not* be root when performing this test: although each script should only display a one-line message about what they're supposed to do, some third-party scripts may not recognize the HP-specific "start_msg" and "stop_msg" arguments, and may actually attempt to start or stop something. Running the commands as a regular user should limit the resulting mess and make it easy to kill off the extra processes.

When you find a startup/shutdown script that outputs a message longer than one line, you've found a potential cause for your problem. If the output length is equal to the total length of each startup/shutdown message (the length of message + dots combined) you're observing, you can be sure you've found the cause.

To fix the problem, edit the problematic script so that it recognizes the "start_msg" and "stop_msg" arguments. When receiving either of those, the script should output a short, simple message and *do nothing else*.

As a consequence of fixing this, you may actually have to re-examine the order of startup scripts you have installed, because the problematic script may have caused a program to be started/stopped earlier than expected.

[Matti_Kurkela]

Um... based on the length of my previous post, I might have been wrong in calling my explanation "simple". :-)

Attached is a script I quickly hacked together to help testing this case.

Basically, it's a stripped-down /sbin/rc from a HP-UX 11.00: I hard-coded it to simulate a "cold boot to runlevel 3" situation instead of auto-detecting the runlevel, and replaced the actual running of the startup scripts with a small loop to display the names of scripts in the assembled checklist and the length of their descriptions. It will also display the length of the longest description: this is what will become the length of each startup message.

Do *NOT* run this as root, unless you're willing to reboot your system immediately afterwards to ensure your system is in a reasonable state.