Strange username for tcpip$inetacp

[Wim Van den Wyngaert]

I booted my system with decnet disabled and tcpip too. And with an empty sysstartup_vms.com. And with decw disabled.

Then I login as SYSMGR_WVW (uic 7,3) and do @sys$manager:systartup.com that contains a submit/user=system. The file that is submitted starts tcpip (and other stuff but out of this scope).

When I normally boot this system it also does the same submits/us.

When I normally boot, the username of TCPIP$INETACP is INTERnet. However, with this "manual" boot I get the username of the one doing the submit (SYSMGR_WVW) instead of SYSTEM.

I get this on 4 GS160 nodes (clusters) but not when I do it on an AS500.

All using VMS 7.3 with tcpip 5.3 eco 2.

WHY ???

Wim

[Wim Van den Wyngaert]

Some evidence enclosed.

Wim

[Dean McGorrill]

well thats interesting. do you have in
your sysmgr_www acount, something in the
login.com that has a redefine of submit? Dean

[Walter Miller_1]

I would start with how does the "User:" get set to INTERnet in a normal startup - there is no user INTERnet in the sysuaf file. Since the TCPIP$INETACP process is started by a simple run 'image' /detached/uic=[1,4]... command in TCPIP$INET_STARTUP.COM, my guess is that SYS$SYSTEM:ECPIP$INETACP.EXE is what sets the "User:" name. Have you checked to see if both the AS500 and GS160 nodes are running the same version of the executable? Also is the AS500 also clusted or standalone?

[Walter Miller_1]

Fumble fingers - of course above I meant SYS$SYSTEM:TCPIP$INETACP.EXE

[Wim Van den Wyngaert]

No redef of submit. As you see in evidence I posted, the job runs under SYSTEM.
The user INTERnet doesn't exists and this is normal. The program that creates the process can put in the field username anything it likes.

Wim

[Robert Gezelter]

Wim,

I do not have the time to experiment here, but I suggest that you do a SHOW PROCESS/ALL in both cases and compare the output. I would also try the same SUBMIT, but from the SYSTEM account (of course, with the same SHOW PROCESS/ALL).

My suspicion is that you will find a difference in the environments surrounding the SUBMIT, most likely in the various privileges that are enabled. SUBMIT/USER= requires CMKRNL, and at least on the one system that I checked (VAX 6.2), gives an error message if CMKRNL is not enabled.

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

[Wim Van den Wyngaert]

Bob,

I have all privs enabled except bypass.
SYSTEM has all privs enabled.

And I don't have a GS160 to test it again. And why is the AS500 not having the problem ?

Note also that the UIC of teh acp is [1,4] (ana/sys).

It's already running for a week without problems. Just hoped someone could explain why it happens.

Wim

[Wim Van den Wyngaert]

Gets stranger.

The cluster is now up for 10 days and 1 of the processes has now name INTERnet. And sometimes it switches back to SYSMGR_WVW.

I tested this in a loop of 1 minute and found the name changes from time to time.

And I ran the same loop on another cluster that was booted normally. Here I also found the acp switching username.

Why o why ?

Wim

[Wim Van den Wyngaert]

When I do a rlogin, it changes username. When I do a logout it's INTERnet again.
Tested it with SYSTEM. User name changed to SYSTEM.

I think the rule is : after someone logs in : his username is assigned to inetacp. It's stays like that until some logout is done (of course tcp related).

Wim