swinstall slow for users with _ in username

[Gordon McKinnon]

I ran into something unusual. I found that on HP-UX 11.11 swinstall runs significantly slower (~10 minutes vs 15 seconds) for users with a username containing an underscore (I used useradd to create test accounts). Does anyone know if this is normal, why it happens, and/or if there is a workaround (other than not using underscores in usernames)? Tusc shows a lot of gettimeofday calls but I was not able to find the root cause.

[Victor Fridyev · Accepted solution]

Hi
AFAIK, only root is permitted to use swlinstall. How do you permit to other users to install sw ?

[Gordon McKinnon]

Excuse me, swlist not swinstall.

[Victor Fridyev]

Hi,

I changed name for one of my users and don't see any change: the command works with the same speed. Do you see anything in

#>dmesg -
or in /var/adm/syslog/syslog.log ?

[Torsten.]

Does your user have a home directory?

What is your user management (/etc/passwd or NIS or ...)?
Did you logged on with this user or just "su"?

[Patrick Wallek]

I just created a user called test_use on one of my 11.11 systems.

I then ran swlist and saw no noticeable time lag. It completed very quickly.

Do you have all of the latest SW* patches installed?

[A. Clay Stephenson]

Is this a trusted or untrusted system? Are you running NIS/NIS+/ or LDAP? Is the user's home directory local or remote with respect to this user. Are you running automounted home directories?

[Gordon McKinnon]

Responses to various questions:

-nothing related in dmesg or syslog
-I'm using /etc/passwd, no NIS on this server, dns only non-files entry in nsswitch.conf
-all the users I tested with have home directories
-I do not have the latest patches installed, on the particular server I've been testing with but I get the same behaviour on numberous servers. I will compare patch levels and explicitly check patch bulletins (tried general searches for HP and google before posting)
-I logged on directly with each user
-one of the users I used was tst_use, it was slow, tstuse user was not.
-Environments for users I tested with were identical (default for server with useradd).

[Gordon McKinnon]

-System is not trusted, standard HP-UX B.11.11. No LDAP, no NFS mounts
-Home directories are local

My setup is quite simple, and the problem surprised me. My analysis went nowhere, I found the problem by trial and error (user question: why is swlist so slow for user x_y?). On the other hand I haven't done much HP-UX in the last ~5 years so I may be missing something obvious.

[Victor Fridyev]

HI,

As a simple test try to replace _ with -
Look on /etc/profile. May be there is a test for usernames, which is not intended for ggg_fff structure.

It's really strange 8((((

[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).

[A. Clay Stephenson]

I haven't looked at the tusc source but for some reason when a -o option is specified, setuid programs won't execute (unless the effective UID is 0). However, this works (but it does mix the trace and swlist's stdout but that's okay).

tusc -T '' /usr/sbin/swlist

should work as a "bad" user and you should then be able to see what the holdup is.

[Gordon McKinnon]

tusc -T ... gives me usage info.

tusc /usr/sbin/swlist as non-root gives (in the output):

ERROR: Could not initialize security. This process does not have
super-user privilege.


and both the tusc and the swlist fail.

[A. Clay Stephenson]

I didn't say tusc -T, I said tusc -T '' -- the -T option expects a time format string even if it's am empty string. When -T '' is supplied the time format is epoch_seconds.microseconds.

[Gordon McKinnon]

Root produces 94 gettimeofday system calls for swlist. A user with an underscore in the name produces more than 13237 (13237 plus the ones after swlist started and before tusc started tracing it.

[Gordon McKinnon]

OK, I thought it was one double quote, not two single quotes...

The gettimeofdays go on for a long time, and then I get output. I suspect I miss the cause in the delay between the start of the command and the time tusc starts to trace. I will try scripting it...