In the TCC instance which issued the REBOOT command causing termination of a session the value of _exit in TCEXIT is 0 ("normal") instead of the appropriate code reflecting the reboot option. Other instances of 4NT and TCC that are also terminated by the logout process report the correct codes.
WAD _exit returns invalid code under some conditions
- Thread starter Steve Fabian
- Start date
I have no idea what you're referring to -- REBOOT is always going to result in a 0 exit code -- unless the REBOOT fails, in which case you'll get a 1 (usage error) or 2 (error exit) return.
I mentioned nothing about the exit code of the REBBOT command. I am discussing the value of the internal variable _EXIT when TCEXIT is performed. If the last command executed in instance X of TCC is the REBOOT command with one of the options /L, /P, /R or /S, the value of _EXIT is 0 in instant X, instead of whatever is appropriate accoring to the REBOOT option used. However, other instances of TCC or 4NT also terminated due to executing the REBOOT command in instance X, the value _EXIT in these other instances correctly matches the REBOOT option.
I still don't understand your point.
First, %_exit will always be 0 in instance X (provided there isn't an error in your REBOOT syntax). Second, the %_exit value in every other TCC instance will be whatever their last internal or external command returned (unless you have an "ON CLOSE / ON SHUTDOWN / ON LOGOFF" handler defined), and is unrelated in any way to REBOOT. There is no value of _EXIT that "correctly matches the REBOOT option".
So your first instance is closed by the REBOOT command, and all of your remaining instances are closed by Windows, and the exit codes will be random at best, and determined by whatever those shells were doing and what you might have in your TCEXIT.
First, %_exit will always be 0 in instance X (provided there isn't an error in your REBOOT syntax). Second, the %_exit value in every other TCC instance will be whatever their last internal or external command returned (unless you have an "ON CLOSE / ON SHUTDOWN / ON LOGOFF" handler defined), and is unrelated in any way to REBOOT. There is no value of _EXIT that "correctly matches the REBOOT option".
So your first instance is closed by the REBOOT command, and all of your remaining instances are closed by Windows, and the exit codes will be random at best, and determined by whatever those shells were doing and what you might have in your TCEXIT.
I don't understand. What about these:
Code:
_EXIT returns the reason for exiting TCC. The possible values are:
0 EXIT command
2 CLOSE_EVENT
5 LOGOFF_EVENT
6 SHUTDOWN_EVENT
Internal variable _exit has nothing to do with command exit codes according to the documentation, quoted below (unchanged since V7):
_EXIT returns the reason for exiting TCC. The possible values are:
0 EXIT command
2 CLOSE_EVENT
5 LOGOFF_EVENT
6 SHUTDOWN_EVENT
My observation is that the above correctly documents 4NT/TCC operation for all instances but X, contrary to your statement above. As you stated, in instance X the value is always 0 - which behavior is contrary to the quoted documentation. The difference between documentation and operation is, IMHO, a B U G !
_EXIT returns the reason for exiting TCC. The possible values are:
0 EXIT command
2 CLOSE_EVENT
5 LOGOFF_EVENT
6 SHUTDOWN_EVENT
My observation is that the above correctly documents 4NT/TCC operation for all instances but X, contrary to your statement above. As you stated, in instance X the value is always 0 - which behavior is contrary to the quoted documentation. The difference between documentation and operation is, IMHO, a B U G !
PS: I wrote my note concurrently with Vince but he posted first... And I would also like to know whether or not my interpretation of the REBOOT command options /R, /S and /P below are correct:
/P perform Windows shutdown, turn off system power (if power supply is controllable by Windows)
/R perform Windows shutdown, immediately restart system
/S perform Windows shutdown, do not turn off power - most systems will automatically restart, not guaranteed
Presumably each of these is a SHUTDOWN_EVENT.
/P perform Windows shutdown, turn off system power (if power supply is controllable by Windows)
/R perform Windows shutdown, immediately restart system
/S perform Windows shutdown, do not turn off power - most systems will automatically restart, not guaranteed
Presumably each of these is a SHUTDOWN_EVENT.
Irrelevant -- your "instance X" (the one that ran the REBOOT command) has exited long before Windows could pass it a shutdown request message. It could only affect instances of TCC that are still running.
To do what you want (keep instance X running after the REBOOT, so it could be shut down by Windows) is not alllowed in Windows.
This is 15+ year old behavior; it is entirely WAD and cannot be changed.
And the entire argument is 90% meaningless in anything newer than XP, since Windows will not allow any of those operations unless you're running an elevated session. REBOOT is essentially obsolete.
To do what you want (keep instance X running after the REBOOT, so it could be shut down by Windows) is not alllowed in Windows.
This is 15+ year old behavior; it is entirely WAD and cannot be changed.
And the entire argument is 90% meaningless in anything newer than XP, since Windows will not allow any of those operations unless you're running an elevated session. REBOOT is essentially obsolete.
Then the whole thing makes sense. The instance receiving the REBOOT command, knowing it would later be asked to terminate, terminates normally (EXIT,0). Since it didn't wait for SHUTDOWN_EVENT, it would be wrong to report that that event was received. Would a new value indicating I_INITIATED_SHUTDOWN_SO_I_TERMINATED_MYSELF_GRACEFULLY be of any value?
I agree with Vince that what I observe makes sense. However, since instance X does perform TCEXIT, in which it can report the value of _EXIT in a log, I'd like its value to be set to a value indicating that neither EXIT nor an external event, but a local REBOOT caused the termination. However, esp. in view of the restriction of using REBOOT in Vista and later, I think just changing the documentation would be sufficient.
On my systems I log the starting and stopping of each command processor instance, and also the calls to the REBOOT command. I do have the means to determine which (EXIT vs. REBOOT) invoked TCEXIT.
Rex,
do any of REBOOT options /H, /K, /L or /W require elevated TCC in Vista et al.? Would not make sense to me... but then all I have is a PERSONAL COMPUTER, not a BOSSING ME AROUND COMPUTER.
On my systems I log the starting and stopping of each command processor instance, and also the calls to the REBOOT command. I do have the means to determine which (EXIT vs. REBOOT) invoked TCEXIT.
Rex,
do any of REBOOT options /H, /K, /L or /W require elevated TCC in Vista et al.? Would not make sense to me... but then all I have is a PERSONAL COMPUTER, not a BOSSING ME AROUND COMPUTER.
Though it is now nearly a year later, I ask: if TCC is running ELEVATED, does REBOOT function in Win7 as it does in WinXP?
Yes, provided your Group Policy supports it. You have to have the SE_SHUTDOWN_NAME privilege enabled.
Thanks. By following the methods in this and other posts in this Forum I succeeded in creating an account on my newly started Win7/64 system where I can run TCMD/TCC elevated, and where the REBOOT command works as it does on WinXP, just as documented.
Similar threads
