[#210] Disable M IO for source server and receiver server before redirecting their stdin/stdout/sdterr or else error messages from them might not show up in their log files #214
Due to code changes in GT.M V6.3-004, fd=0 (stdin) was being duped to a fd that
points to /dev/null. But io_init has already happened in the parent source server
startup command process and so any errors (NULLCOLLDIFF error does a gtm_putmsg_csa)
go through util_out_print_vaparm() eventually which incorrectly decides to use the
M device for writing the error (that still points to stdin i.e. fd=0 which was the
terminal at source server startup but has now been redirected to /dev/null later).
Therefore, the error message ends up nowhere. But the source server startup fails
and the user has no clue why it failed. Errors that could be missed out are
NULLCOLLDIFF, REPLOFFJNLON, REPLINSTNOHIST etc.
A workaround for this issue in V6.3-004 is to redirect stdin to say /dev/null as part of
the source server startup command. This would cause the device corresponding to stdout
to be opened as the M device at io_init time thereby causing the error to be written
through fd=1 which is okay since fd=1 has been redirected to the source server log file.
Similar issue exists with the receiver server except that it does not issue any
errors with gtm_putmsg_csa() like the source server in the early stages of the startup
and so that is not as user-visible an issue as the source server one.
While at this, noticed "io_std_device" is a structure global variable that is declared
as GBLREF *io_std_device in some modules and GBLREF io_std_device in most other modules.
Not sure how this works fine but have made it consistent by making it all the latter.
Due to code changes in GT.M V6.3-004, fd=0 (stdin) was being duped to a fd that points to /dev/null. But io_init has already happened in the parent source server startup command process and so any errors (NULLCOLLDIFF error does a gtm_putmsg_csa) go through util_out_print_vaparm() eventually which incorrectly decides to use the M device for writing the error (that still points to stdin i.e. fd=0 which was the terminal at source server startup but has now been redirected to /dev/null later). Therefore, the error message ends up nowhere. But the source server startup fails and the user has no clue why it failed. Errors that could be missed out are NULLCOLLDIFF, REPLOFFJNLON, REPLINSTNOHIST etc.
A workaround for this issue in V6.3-004 is to redirect stdin to say /dev/null as part of the source server startup command. This would cause the device corresponding to stdout to be opened as the M device at io_init time thereby causing the error to be written through fd=1 which is okay since fd=1 has been redirected to the source server log file.
Similar issue exists with the receiver server except that it does not issue any errors with gtm_putmsg_csa() like the source server in the early stages of the startup and so that is not as user-visible an issue as the source server one.
While at this, noticed "io_std_device" is a structure global variable that is declared as GBLREF *io_std_device in some modules and GBLREF io_std_device in most other modules. Not sure how this works fine but have made it consistent by making it all the latter.