Although the current NoUI mode works exactly as documented, on UN*X style platforms the tty handling is not intuitive and doesn't behave well if the user fails to understand the importance of redirecting the input and output exactly as documented:
hercules --NoUI -f conf/vm370uts.conf --logfile logs/log.txt </dev/null >/dev/null 2>&1
@Fish-Git Please can you assign this Issue to me so that it can be used to discuss the solution(s) to this "UN*Xism"? I have tried to ensure that no Windows handling has been changed using if !defined( _MSVC_ )
A typical UN*X trick is to create a command starter e.g. hstart
#!/bin/bash
hercules --NoUI -f conf/vm370uts.conf --logfile logs/log.txt
and then use nohup hstart & to run Hercules in the background so that user can log off (nohup does the IO redirection for the user).
Whilst this works, this appears in the log file:
HHC02260I Script 2: begin processing file <stdin>
HHC02219E Error in function read(): Bad file descriptor
HHC00007I Previous message from function 'process_script_file' at script.c(867)
HHC02265I Script 2: file <stdin> aborted due to previous conditions
behind the scenes this error is telling us that Hercules is trying to read from the now redirected stdin. [ nohup redirects stdin to /dev/null as WRITABLE only, specifically to catch programs not detaching properly. ]
Using hstart just with & is interesting. Here is the shell session in that case. Notice how Hercules has stopped as it's trying to read from the user's tty.
vm@mvs5ssd:~/VM $ ./hstart.sh &
[1] 504947
vm@mvs5ssd:~/VM $ HHC00109E set_thread_priority( 5 ) failed: Operation not permitted
HHC00007I Previous message from function 'impl' at impl.c(1352)
HHC00110W Defaulting all threads to priority 1
HHC00007I Previous message from function 'impl' at impl.c(1356)
[1]+ Stopped ./hstart.sh
Once the user reattaches to the job, processing carries on. However, once the user terminates Hercules from the HTTP console, this output is spewed to the users tty.
HHC01423I Calling termination routines
HHC00101I Thread id 00007fff5054f140, prio -1, name 'socket_thread' ended
HHC00101I Thread id 00007fff5015b140, prio -1, name 'http_server' ended
HHC00101I Thread id 00007fff5037b140, prio -1, name 'Processor CP00' ended
HHC00101I Thread id 00007fff3bfff140, prio -1, name 'console_connect' ended
HHC00333I 0:06A0 32/64 size free nbr st reads writes l2reads hits switches
HHC00335I 0:06A0 ------------------------------------------------------------------------
HHC00336I 0:06A0 [*] 32 00018029650 000% 0000 0000001 0000000 0000001 0000000 0000001
HHC00338I 0:06A0 disks/gccbrx.cckd
<<< loads of lines deleted >>>
HHC00339I 0:0153 [0] 32 00000003678 000% 0000 rw 0000001 0000000 0000001
HHC00101I Thread id 00007fff3b9ef140, prio -1, name 'cckd_ra thread 2' ended
HHC00101I Thread id 00007fff3baff140, prio -1, name 'cckd_ra thread 1' ended
HHC00101I Thread id 00007fff3b7cf140, prio -1, name 'cckd_dh' ended
HHC00101I Thread id 00007fff3b6bf140, prio -1, name 'cckd_writer thread 1' ended
HHC00101I Thread id 00007fff3b5af140, prio -1, name 'cckd_writer thread 2' ended
HHC01427I Main storage released
HHC01427I Expanded storage released
HHC01422I Configuration released
HHC01424I All termination routines complete
HHC01425I Hercules shutdown complete
HHC01412I Hercules terminated
These two cases demonstrate that something is slightly awry.
I decided to investigate exactly what is happening and it turns out the fix for the tty handling is trivial:
EDITED TO fix logic error and also add in missed wsnslport commit that crossed in the ether.
The changes, only apply when started in NoUI mode:
- correctly handle the processing of the "-" script file during startup so it doen't read from either the user's tty or a nohup redirected /dev/null
- detaches the user's tty very early in the startup so that stdout and stderr output is not spewed to the user's tty session.
HOWEVER, it does raise another issue that I plan on working through as part of this.
A user would expect that using the --logfile option would place all of the output from Hercules into the specified file. BUT it appears that during shutdown processing the logger thread is the first to quit! This is why the examples, pre the impl.c fix, show output spewed to the users session - that spewed output does NOT appear in the --logfile.
Ideally, the logger should hang around during the majority of shutdown so that the --logfile contains all of the log.
Could I ask that LINUX / MacOS users give the impl.c change a test drive and report back on if it helps or not?
Meanwhile, I'll try and unravel the logger shutdown flow.....
Although the current NoUI mode works exactly as documented, on UN*X style platforms the tty handling is not intuitive and doesn't behave well if the user fails to understand the importance of redirecting the input and output exactly as documented:
hercules --NoUI -f conf/vm370uts.conf --logfile logs/log.txt </dev/null >/dev/null 2>&1@Fish-Git Please can you assign this Issue to me so that it can be used to discuss the solution(s) to this "UN*Xism"? I have tried to ensure that no Windows handling has been changed using
if !defined( _MSVC_ )A typical UN*X trick is to create a command starter e.g. hstart
and then use nohup hstart & to run Hercules in the background so that user can log off (nohup does the IO redirection for the user).
Whilst this works, this appears in the log file:
behind the scenes this error is telling us that Hercules is trying to read from the now redirected stdin. [ nohup redirects stdin to /dev/null as WRITABLE only, specifically to catch programs not detaching properly. ]
Using hstart just with & is interesting. Here is the shell session in that case. Notice how Hercules has stopped as it's trying to read from the user's tty.
Once the user reattaches to the job, processing carries on. However, once the user terminates Hercules from the HTTP console, this output is spewed to the users tty.
These two cases demonstrate that something is slightly awry.
I decided to investigate exactly what is happening and it turns out the fix for the tty handling is trivial:
EDITED TO fix logic error and also add in missed
wsnslportcommit that crossed in the ether.The changes, only apply when started in NoUI mode:
HOWEVER, it does raise another issue that I plan on working through as part of this.
A user would expect that using the --logfile option would place all of the output from Hercules into the specified file. BUT it appears that during shutdown processing the logger thread is the first to quit! This is why the examples, pre the impl.c fix, show output spewed to the users session - that spewed output does NOT appear in the --logfile.
Ideally, the logger should hang around during the majority of shutdown so that the --logfile contains all of the log.
Could I ask that LINUX / MacOS users give the impl.c change a test drive and report back on if it helps or not?
Meanwhile, I'll try and unravel the logger shutdown flow.....