swinstall slow for users with _ in username

[Gordon McKinnon]

Behaviour is the same with direct login and with su.

[Torsten.]

Did swlist give a result or an error?

Any messages in /var/adm/sw/swagentd.log?

Username less than 8 characters?

[A. Clay Stephenson]

I readily admit that I am using "The Force" but try killing (and not restarting) pwgrd. I seen this stupid daemon do so many strange things that I would not be surprised at all if this fixes you. UNIX boxes ran for decades without this thing and yours will too.

[Gordon McKinnon]

Swlist did not produce any errors. Output is identical to accounts that do not have a _ in the username, except for the delay.

None in the last month.

I did not test with any users with usernames longer than 8 characters.

[Gordon McKinnon]

Killing pwgrd (used the init script) did not speed up the swlist. Neither did starting it again.

[Torsten.]

I can't imagine a difference here, but try to get the hostname

# hostname

and name resolution

# nslookup

What could be different between the users beside the name?

[A. Clay Stephenson]

I did find a patch for swagentd that does indicate performance problems with uid lookups especially on systems running pwgrd.

I would install PHCO_30243 and PHCO_34539.

You might find that simply restarting swagentd after stopping pwgrd cures you all by itself.

[Gordon McKinnon]

Name resolution works fine for all users as far as I can see. I've done everything I can think of to create users that differ only in username (and only by one character).

Hmm, from another post:

Avoid the characters that have special meaning to the 'getty(1M)' login process.

These characters are #, @, /, !, _, backspace, ^U, ^D, or &.

See the manpages for 'getty(1M)' for more information.

[A. Clay Stephenson]

Let's do one more thing.

tusc -o /var/tmp/badtusc.txt -T '' /usr/sbin/swlist

executing as one of your "bad" users. The timestamps in the tusc output should help you find the hang especially if you compare it to a run under a "good" user.

[Gordon McKinnon]

Tusc will only trace swlist if run as root, so comparing good and bad output is a little tough (by the time a ps completes to get the pid for the swlist the process has finished and there is nothing to tusc...)

A tusc swlist by pid run by an underscored username gives a lot of

[27288] poll(0x7f7f4848, 1, 0) ........................... = 0
[27288] gettimeofday(0x7f7f4bb8, 0x7f7f4c18) ............. = 0
[27288] gettimeofday(0x7f7f4e58, 0x7f7f4e98) ............. = 0
[27288] gettimeofday(0x7af7ceb0, 0x7f7f4f98) ............. = 0
[27288] set_userthreadid(2) .............................. = 0
[27288] gettimeofday(0x7af7ceb0, 0x400c1748) ............. = 0
[27288] select(8, 0x7af7d930, 0x7af7d830, 0x7af7d730, 0x400c1680) = 0
[27288] gettimeofday(0x7af7ceb0, 0x400c1748) ............. = 0
[27288] select(8, 0x7af7d930, 0x7af7d830, 0x7af7d730, 0x400c1680) = 0
[27288] gettimeofday(0x7af7ceb0, 0x400c1748) ............. = 0
[27288] set_userthreadid(1) .............................. = 0
[27288] poll(0x7f7f4848, 1, 0) ........................... = 0
[27288] gettimeofday(0x7f7f4bb8, 0x7f7f4c18) ............. = 0
[27288] gettimeofday(0x7f7f4e58, 0x7f7f4e98) ............. = 0
[27288] gettimeofday(0x7af7ceb0, 0x7f7f4f98) ............. = 0


but I don't see an obvious problem (other than the fact that there are so many gettimeofday calls).