How Are Process Names Generated?

[Kevin Atchley]

Greeting's All
(1st time poster ... please bear with the newbie)

We are running a system on VMS v7.3-1, and have noticed something peculiar. When doing a SHO USER /FULL, it shows a list of all user's logged into the system, along with the process name associated with each user. In all most all cases the process name matches the user name. However, in some cases the process name shows up as "_LTAxxxx:". This is causing a problem as we have some local code that grabs the process name and writes it to a log file, when it logs the "_LTAxxxx" we have no way of knowing what person we were logging information about at that time. And no .. i don't know why our local code was written this way, but it apparently cannot be changed easily so I was asked to find out why the process names were showing as they are.

After doing some digging in manuals it seemed to me that there should never be duplicate process names within a given group. However, this does not seem to match what I am seeing on our system. If I do a SHO PROC /ALL /ID=xxxxxxxx I get the following information about several of the processes on his system:

MAGA:CSKTA> pipe sho proc/all/id=0011E30D | sea sys$input "User I", "ess name"
Node: MAGA Process name: "RANGE"
User Identifier: [CONTR,RANEFF]
MAGA:CSKTA> pipe sho proc/all/id=00114117 | sea sys$input "User I", "ess name"
Node: MAGA Process name: "RANGE"
User Identifier: [CONTR,RANEFF]
MAGA:CSKTA> pipe sho proc/all/id=000E9160 | sea sys$input "User I", "ess name"
Node: MAGA Process name: "RANGE"
User Identifier: [CONTR,RANEFF]
MAGA:CSKTA> pipe sho proc/all/id=000E2A37 | sea sys$input "User I", "ess name"
Node: MAGA Process name: "_LTA1278:"
User Identifier: [CONTR,RANEFF]

As you can see the User Identifiers for all processes match (which I assume points to what group they belong, however the process names for some are the same and for some are different.

So my question is .... How does the system determine what the processes name is for a user when they log in, why are some of the process names identical and why are some of them "_LTAxxxx:" processes, and if I am looking at the wrong information what information should I be looking at?

TIA for all you help,
-k

[Uwe Zessin]

Welcome to ITRC forums!

It depends on the application which name a process is assigned. As you have found out, process names must be unique in a UIC group. For this reason, a new interactive process receives the terminal's name (e.g. _LTA123:). At this stage, the authorization is not done and the username is unknown.

During login of the user (I think it is in LOGINOUT.EXE) an attempt is made to change the process name to the same value as the username. If this one fails due to a duplicate process name, the old name (_LTA123:) is retained.

[Uwe Zessin]

Oh, by the way:
> User Identifier: [CONTR,RANEFF]

This has nothing to do with the process name. It is a binary/ textual translation from the process' UIC. CONTR is an identifier for the UIC group and RANEFF for the member in that group.

Go into AUTHORIZE and check:
UAF> show /identifier CONTR
UAF> show /identifier RANEFF

--

For fun(?), you can play a bit:
UAF> rename /identifier CONTR ABC
UAF> rename /identifier RANEFF DEF
UAF> show RANEFF

$ pipe ...

[Phillip Thayer]

Most of the sites I have worked at have implemented something at login in SYLOGIN.COM that will set the username to USER_1, USER_2, USER_n depending on how many times the USER is logged on. It is actually pretty simple to do.

$ usr_name=f$getjpi("","USERNAME")
$ if f$len(usr_name).gt. 13
$ then
$ usr_name=f$extract(0,13,usr_name)
$ endif
$ count=0
$ set message/nof/noi/nos/not
$LOOP:
$ count = count + 1
$ if count .gt. 9
$ then
$ goto max_logins_exceeded
$ endif
$ set process/name="''usr_name'_''count'"
$ if .not $status then goto loop
$ goto exit_com
$!
$MAX_LOGINS_EXCEEDED:
$ write sys$output ""
$ write sys$output "maximum logins exceeded for account"
$ write sys$output
$ logout
$!
$EXIT_COM:
$ exit

To increase the number of maximum logins to a two-digit number you would have to limit the main use-name to 12 characters instead of 13 and change the check of count after it is incremented.

Phil

[Robert Gezelter]

Kevin,

Welcome to the OpenVMS Forum.

For starters, it would be helpful to see the complete SHOW SYSTEM output.

Process names are initially based on usernames, but can be reset using the SET PROCESS/NAME=xxx command. When a user is already signed on, the name will default to the name of the device that session logged in from.

Your better bet on associating users with actions is to use the accounting file, and the processid. Process ID is unique within a cluster lifetime.

I hope that the above is helpful

- Bob Gezelter, http://www.rlgsc.com

[Uwe Zessin]

A PID is unique within a cluster at a given time, but the 'reuse' counter (don't know the correct term, sorry) in the PID is only a few bits if you have a large MAXPROCESSCNT. So PIDs _can_ come up again if a node runs long enough and sees lots of process creations.

[Lawrence Czlapinski]

Kevin, you would probably want to exclude username SYSTEM and possibly others from your process naming scheme. You may also want to identify non-interactive jobs differently (such as batch jobs). We often do a: "$set proc/name= process_name" for our batch jobs to indicate what there function is. So you may want to use the lexical f$mode():
$ if f$mode() ... ! HELP Lexicals f$mode
$ then
...
$ endif
Lawrence

[Kevin Atchley]

Thank you all for your response, however I still don't quite have the information I was looking for. Allow me to elaborate.

Doing a SHOW USER/FULL, we have the following users logged in:

Username Process Name PID Terminal
RANGE RANGE 000D4808 LTA1187: (MAGT06/TS63)
RANGE RANGE 000F900C LTA1338: (MAGT0T/TST7)
RANGE RANGE 000B8E2B LTA1389: (MAGT0M/TSM6)
RANGE RANGE 000F2A36 NTY8542: (ccc-ornent)
RANGE RANGE 00088095 LTA1717: (MAGT0M/TSM2)
RANGE RANGE 000CF896 LTA1946: (MAGT0X/TSX3)
RANGE RANGE 0008A2A2 LTA1781: (MAGT0O/TSO2)
RANGE RANGE 000D06A6 LTA1240: (MAGT09/TS97)
RANGE RANGE 000B36B9 LTA1328: (MAGT08/TS81)
RANGE RANGE 000C46BB NTY8995: (23aal66.milliken.com)
RANGE RANGE 000EB4C4 LTA1247: (MAGTBB/TSBB5)
RANGE RANGE 00086CD8 LTA1752: (MAGT09/TS95)
RANGE RANGE 00102EF2 LTA1299: (MAGT0R/TSR4)
RANGE RANGE 001168F4 LTA1823: (MAGTFF/TSFF5)
RANGE RANGE 00107305 LTA1393: (MAGT06/TS66)
RANGE RANGE 0011E30D LTA1841: (MAGT06/TS64)
RANGE RANGE 00114117 LTA1372: (MAGT0O/TSO6)
RANGE RANGE 000CBF2A LTA1607: (MAGT0O/TSO1)
RANGE RANGE 0010E530 LTA1949: (MAGT09/TS93)
RANGE RANGE 000E9160 LTA1409: (MAGT0T/TST8)
RANGE _LTA1237: 000AD0FC LTA1237: (MAGT0O/TSO8)
RANGE _LTA1278: 000E2A37 LTA1278: (MAGT0I/TSI1)
RANGE _LTA1580: 0011FF33 LTA1580: (MAGT04/TS48)

The question we have is why do some of the users have Username RANGE and Process Name RANGE, while others have Process Name LTAxxxx:? They should all be in the same group as they are all doing the same thing and logging in under the same account. We are more interested in finding out why there are some showing up as LTAxxxx: because we want those to show Process Name the same as User Name. Again, I don't know why our code was written to use Process Name when logging entries, but i have been told it's not something they want to try and change (if they can get around it).

Again, TIA for your help,
-k

[Robert Gezelter]

Kevin,

Please submit the output of SHOW SYSTEM and SHOW USERS/FULL without any filtering. Then we will be able to fairly identify exactly what is happening.

Posting filtered outputs does not help.

- Bob Gezelter, http://www.rlgsc.com

[John Gillings]

-k

The default algorithm for generating a process name is fairly simple minded. First attempt is to set the process name to the user name. If that's not unique within the group, then use the terminal name "_LTA1234:"

If you have multiple processes on your system within the same group that have the same (apparent) process name, then there must be some tricky code which is forcing that to happen, because OpenVMS isn't supposed to allow it.

It's possible that someone has written code executed at login which sets the process name to "RANGE" with space characters appended. Since the process name limit is 15 characters, that would give you 10 extra processes with names that LOOK the same from SHOW USERS. There may be other non-printing characters you could use as well, giving a few more. Once you've run out of combinations, maybe it just gives up and leaves the process name as the terminal name?

The uniqueness restriction isn't very hard - one fairly simple way to create two processes with the same name:

1) Login as yourself - this creates a process with name=username
2) Login again, this will give you something like _LTA1234: or _TNA4567:
3) Work out what the next LTA or TNA number will be and use SET PROCESS/NAME to rename your second process to that name
4) Login again. If you predicted correctly, you will now have 2 processes with the same name.

The process naming logic assumes that no existing process will use the name of the current process.


Bottom line here is whatever is happening on your system is site specific, as there isn't any logic in OpenVMS which would give you a SHOW USERS display like the one you've posted.

[Antoniov.]

-k,
my welcome to vms forum.

I think, like other guys, you have a login code to set process name to RANGE*.
Look at SYS$MANAGER:SYLOGIN.COM, you should see the reason of it.

Antonio Vigliotti

[Kevin Atchley]

Thank You All,

I think I am getting closer to understanding why it is happening, but now the questions is HOW is it happening. I have read that there can not be two processes with the same process name in the same group. So my question is, why/how can we have 20 processes with process name RANGE whan they are all logging in under the same usreid? I would assume they would have to be in different groups, and I'm sure we do have some local code in place that is changing process names and possible even group assignments, but how do I verify this? i.e. What information in SHO PROC /ALL/ID=xxxxxxxx points out that these two (or twenty) processes are in different groups?

Thanks to all,
(point will be assigned shortly)

-k

[Wim Van den Wyngaert]

Check the full process name surrounded by quotes with :
$ sh proc/id=xxx
Then you will see the blanks behind RANGE.

Wim

[Antoniov.]

Hi -k,
I have a crazy idea ...
- I guess you have some automatic procedure to assign process name;
- I guess this procedure has some bug
So look at follow code:
$! Set radix (may user name)
$ PROCNAME="RANGE"
$! Set counter (in wrong mode)
$ ID[0,16]=1
$! Set full process name
$ MYNAME=PROCNAME+ID
$! Now I set my process name
$ SET PROC/NAME="''MYNAME'"
I know it uneasy to read so after equal characters are MYNAME
This is not tha same but it's just to show how use undisplayable characters.

Antonio Vigliotti

[Jeffery D. Urmann]

Kevin,

In an effort to help you narrow your search, have a look at the login command procedure, if any, for the username Range:

$ Pipe MCR Authorize Show /Full Range | Search Sys$InPut "LGICMD"

Then Search this file for possible process name code as others above have suggested.

Enjoy,

--Jeff

[Kevin Atchley]

Again, Thank You All,

Antonio, I have had some luck in creating duplicate process names for the same user name following some of the suggestions you left. I'm not sure if this is what we are doing, but I will start looking at our code to find out if this is the culprit.

Also, in response to several other suggestions i can say that the usernames are not being padded with spaces to give the "appearance" of similar process names. Doing a f$length( f$getjpi("pid","PRCNAM)) on the processes shows the process name for all of them is the same length. Also, there is nothing special in the system or user login procedures that is making these changes, but there is other local code to be looked at.

Again, I have heard that duplicate process names are not allowed in a specific group (which I know can be circumvented with a few tricks). I am still wanting to find out what this "group" is? Is this the UIC for the account that was logged in while the process name was being assigned? Is there some way to see what "group" the process is in, such as a SHO PROC /ALL? How can I verify that all of the processes are in different groups (or the same group)?

Thanks,
-k

[Volker Halle]

Kevin

$ SHOW SYS/FULL shows the UIC of the process as the first item in the 2nd line of each process display.

F$GETJPI("pid-of-process","GRP") shows the group-UIC as a decimal number.

SHOW PROC/ID=pid-of-process shows the User Identifier as: [group-name,username]

If there is no group-UIC (= [group,177777]) name defined for a group, only the username will be shown as the user identifier.

Volker.

[Antoniov.]

-k,
now use brute force to search what you want.
$ SEARCH SYS$MANAGER:SYLOGIN.COM -
"SET","PRO","NAME" /MAT=AND
If necessary you can extend this search to all .com files of system
$ SEARCH SYS$DEVICE:[000000...]*.COM -
"SET","PRO","NAME" /MAT=AND/OUT=

Antonio Vigliotti

[Kevin Atchley]

Thank you all for your generous help.

We have finally determined what was happening, and why we were seeing the odd behavior. As it turns out, when the users log into the server, they go into a custom written menu. The menu, among many other things, changes the UIC of the user's process as it traverses the menu. The issues we were seeing were nothing more than a timing issue. When the 1st user logged in, they started in group [00100] and had process name = user name; they went into menu and changed UIC to [00250]. The next user logged in and started in group [00100] with process name = user name; they went into menu and their UIC changed to [00250]. Now, when user #3 logged in with UIC [00100] and process name = user name, they DID NOT go into menu. So when user #4 logged in with UIC [00100], their process name did not change to match user name, it stayed the _LTAxxxx that VMS assigned it. And so on, and so on, and so on....

Thank you all for your help and the information you presented.

Have a good day,
-k

[Kevin Atchley]

{see description of solution above}

[Robert Gezelter]

Kevin,

Generally, it is a not a good idea for processes to change their UICs as a matter of course. This requires the use of privileged facilities, which can only weaken the overall security of the system.

The security and other implications are seerious. These privileges potentially allow users the ability to modify the files containing VMS itself, among other things. In all the cases that I have seen, the effects of changing the UIC can be achieved in a fully secure way, without the use of privileges, through the use of the appropriate ACLs.

I hope that the above is helpful.

- Bob Gezelter, http://www.rlgsc.com