Hp console using putty

[Bill Chan123]

Server boot up showing a long dot .... lines

HP-UX Start-up in progress
__________________________

Configure system crash dumps ........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................ OK
Removing old vxvm files ...........................................................................................................................................................

[Dennis Handly]

(You don't need to provide all of those ".". Just count up the total.)

Using putty, somehow your line length ($COLUMNS) is set to a very large value. You don't have TERM set correctly?

[Kapil Jha]

Which version is this, and hardware model.
I have see same thing in old boxes I guess.

BR,
Kapil+

[Bill Hassell]

Are you using the real console (MP or GSP)? Many of the GSP and MP revisions have suppressed reporting of LINES and COLUMNS through ttytype and tset. You may have the GSP/MP set to hp rather than vt100. Set the terminal on the GSP/MP to vt100. And as an aside, make sure you don't have TERM=vt100 hardcoded in /etc/profile or .profile. Instead, use the ttytype command followed by resize to handle both the console as well as HP-UX LAN ports:

## export TERM=100 <- don't use
eval $(ttytype -s)
eval $(resize)

[Matti_Kurkela · Accepted solution]

One of your startup scripts is producing a multi-line output when called with the "start_msg" argument. It should not do that.

In HP-UX, a startup script is supposed to only produce an appropriate short (one-line) message and do nothing else when called with "start_msg" or "stop_msg".

When HP-UX is starting up, the main sequencer script /sbin/rc first collects all the start-up messages from each init script that is configured to run in the target runlevel, by running each script with a "start_msg" argument. Only after this is done, it will run them again using the "start" argument.

If the console is a workstation screen or a HP 700/9x terminal configured in native HP mode, /sbin/rc generates a fancy multi-page startup display where each page is first displayed in its entirety, and as soon as each start-up script is executed for real, an OK, FAIL or N/A will appear inside the empty brackets at the end of the appropriate line. In a workstation screen, you'll even see FAIL/NA/OK in red/yellow/green colors, respectively.

If the console is running on any other type of terminal, a simpler display format is used... but the dots are still used to align the "OK/FAIL" results in the same column on each line. If any of the init scripts produces multi-line output when run with the argument "start_msg", the alignment algorithm counts 80 characters for each line except the last one. This is then applied to all startup messages... resulting in long strings of dots.

A similar procedure happens when shutting down the system, but in this case, the scripts are run with arguments "stop_msg" and then "stop".

To find the cause of your problem, run all your custom init scripts with argument "start_msg". When run in this way, no script should actually start anything, only display an one-line startup message. If a script produces multi-line output or actually tries to start something, the script is inappropriate for use on HP-UX as is, and needs a little bit of fixing.

A script such as this might be used to see the startup and shutdown messages of all configured init scripts at once (disclaimer: not tested):

#!/bin/sh
for i in /sbin/rc?.d
do
for j in $i/S*
do
echo "Startup script $i/$j:"
sh "$i/$j" start_msg
done
for j in $i/K*
do
echo "Shutdown script $i/$j:"
sh "$i/$j" stop_msg
done
done

Any init script that produces multi-line output when called by this script is likely to cause the "long lines of dots" problem at startup and/or shutdown.

MK

[Dennis Handly]

>Matti: One of your startup scripts is producing a multi-line output when called with the "start_msg" argument.

Why do you think this is more complex than what Bill and I suggested? This is HP's rc script trying to pad out a bogus very long line length. The first is "Configure system crash dump".

I suppose one way to prove this is to echo $COLUMNS in one rc(1m) script, after you reboot.

[Matti_Kurkela]

I've experienced a problem with the exact same symptoms, and solved it. In my case, it was *NOT* related to $COLUMNS at all.

Run "grep COLUMNS /sbin/rc /sbin/rc.utils": you will see that such a variable is never used in the scripts that produce the startup checklist. The string "COLUMNS" is there, but only as a comment.

On the other hand, when I fixed a third-party application startup script that originally was pure SystemV by adding the HP-UX-specific "start_msg" and "stop_msg" handling, the problem went away. I cross-checked: that was the *only* change between the good and bad states, and re-introducing the old version of the startup script made the problem re-appear with 100% repeatability, in HP-UX versions 11.00 - 11.23. I see no reason why the situation would be different in 11.31.

At that time, I investigated the problem in some detail. Based on that, I can confidently say that:

1.) If the checklist display is in "line mode", the console line length is never checked at all.

2.) If the console terminal is a HP terminal (or an emulator of such one) or a workstation ITE display, the checklist display can be in "screen mode". In that mode, the line length is checked, but *not* by using the COLUMNS variable.

--------
Here's a non-formal proof for my claims:

See /sbin/rc.utils, which is used by /sbin/rc to create the startup/shutdown messages. With the default settings, the system will use the is_terminal_hp function to detect whether the console is a real HP terminal, an ITE workstation display, or something else. For a real HP terminal or an ITE, the "screen mode" is used.

If the console is not positively identified as a HP terminal or an ITE, or the /etc/rc.config.d/list_mode forces line mode, the startup display is generated by the do_line_mode() function in /sbin/rc.utils. In it, the length of lines is determined in a very simple fashion:

let LINE_LENGTH="$LONGEST_DESC + LINE_PAD"

The do_line_mode() function uses echo_item() (also in rc_utils) to display each output line. It simply echoes the start_msg/stop_msg message, and then fills the line with dots until $LINE_LENGTH is reached.

The $LONGEST_DESC variable contains the length of the longest description. This is produced by the add_list() function and is used in all display modes.

In the do_line_mode() function, there is no check of terminal line length *at all*. The length of the checklist lines will be the length of the longest output received when calling the startup scripts with the start_msg/stop_msg argument.

In do_screen_mode() function (which is used only with HP terminals and ITEs), the terminal line length is determined by calling inquire_row_col(), which directly sends an escape sequence to the terminal and interprets the response: $COLUMNS variable is not used at *any* point.

Instead the functions define their own variables $COLS and $AVAIL_COLS (= console width - margins - checkbox width) using the response to the escape sequence. These variables are then used to limit the length of the start_msg/stop_msg description text... but this happens only in screen mode.

MK

[Dennis Handly]

>Matti: In my case, it was *NOT* related to $COLUMNS at all.

So it looks like we need to do your experiment after all.

>If the console is not positively identified as a HP terminal or an ITE,

Ok, that might leave putty out.

>The $LONGEST_DESC variable contains the length of the longest description.

So you are saying, that there could be some other message that wasn't listed that was bogus? Or some escaped stdout text that did it?

>which directly sends an escape sequence to the terminal and interprets the response: $COLUMNS variable is not used at *any* point.
>Instead the functions define their own variables $COLS ...

Bill and I were thinking this could go wrong, it doesn't have to materialize the exact variable COLUMNS.

[Bill Chan123]

Thank everyone helping

One of the start up script does not have start_msg & stop_msg. Problem resovled after put back
case "$1" in
start_msg)
echo "Starting Agent";;
stop_msg)
echo "Stopping Agent";;

[Matti_Kurkela]

(Oh, the thread was closed while I was typing this. Anyway, for those interested in technical details... )

>>If the console is not positively identified as a HP terminal or an ITE,

>Ok, that might leave putty out.

I find that almost a certainty. As far as I know, PuTTY is still a xterm/VT100-compatible terminal emulator. Unless it has suddenly gained an entirely new HPterm emulation mode, screen mode does not happen with PuTTY.

As the original poster's example output does not have square brackets around the "OK", the output is definitely in line mode. The screen mode's output would look like
"... [ OK ]".

In line mode, the terminal type is not an issue: the line mode is thoroughly terminal-type-agnostic and does not use any control sequences at all.

(By the way, the screen mode is also designed to be somewhat fail-safe: if the terminal's response to the row/column number query seems nonsensical, /sbin/rc falls back to line mode.)

>So you are saying, that there could be some other message that wasn't listed that was bogus? Or some escaped stdout text that did it?

Emphatically yes to the first question. The second is also possible, though I would not find it as likely.

The non-obvious bit (which I completely failed to emphasize before) is that even in line mode, the /sbin/rc will make two passes through the /sbin/rc?.d scripts.

On the first pass, it will gather the start_msg/stop_msg messages from *all scripts it's going to use*, store them into a table, and remember the length of the longest one in $LONGEST_DESC. At this point, nothing is displayed on the console yet.

On the second pass, /sbin/rc will run the scripts with the actual start/stop argument.
Before running each script, it displays the appropriate message gathered on the first pass, extended with dots to $LONGEST_DESC length. After the script has been executed, /sbin/rc will append the OK/NA/FAIL to the output line, according to the result code of the script.

This two-pass processing is obviously necessary for the screen mode, but the line mode does it too, probably to make the checklist output modes easier to implement.

So, even though the problem is visible with standard HP-UX startup steps like "Configure system crash dumps", the actual cause may be the commercial application whose start script was added to /sbin/rc3.d/S999CommercialApp, even though it's message is nowhere in sight yet... because on the first pass, its over-long message pushed the $LONGEST_DESC into absurdity.

In my case, the problem was a commercial multi-platform monitoring application whose start-up script could not process the HP-UX-specific start_msg/stop_msg arguments. If the application's script was executed, the result was something like this:
----
# /sbin/init.d/MonitoringAgent start_msg
< ^L emitted for clearing the screen >
Monitoring Agent configured to port XXXX

At least two long lines of copyright messages

Unknown argument 'start_msg'
Usage:
/sbin/init.d/MonitoringAgent < start | stop >
#
----

Of course this pushed the $LONGEST_DESC well above 80 characters, so *all* startup checklist messages got a long ugly string of dots appended to them.

This was fixed by adding to the beginning of the script ( = before it output anything else) a small extra test:

case "$1" in
start_msg)
echo "Starting MonitoringAgent"
exit 0
;;
stop_msg)
echo "Stopping MonitoringAgent"
exit 0
;;
esac

Of course, if the problematic script follows the structure of normal SysVinit startup scripts, the handling of start_msg and stop_msg can be added to the main "case" statement of the startup script. But in my case, the script obnoxiously wanted to output things even before entering the main "case" statement, so I had to add an extra test before all other output.

MK