Skip to content

Improve --NoUI mode when running on non-Widows platforms #849

Description

@agadsby

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

Metadata

Metadata

Assignees

Labels

BUGThe issue describes likely incorrect product functionality that likely needs corrected.IN PROGRESS...I'm working on it! (Or someone else is!)

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions