- changed status to open
- removed comment
redirect stdout and stderr of all processes if requested (also of the root process)
Currently Cactus only redirects, when asked, stdout and stderr to files for processes other than the root process. The patch lets Cactus also write stdout and stderr for the root process.
https://bitbucket.org/cactuscode/cactus/pull-request/2/redirect-stdout-and-stderr-of-all/diff
Keyword:
Comments (17)
-
reporter -
- removed comment
Is this handled via a new option, or does this change the behaviour of the existing option? If so, is stdout/stderr of the root process duplicated into files, or is it redirected?
-
reporter - removed comment
It is also written to files for process 0. The patch only removes the "if (myproc)" statement. No new option.
-
- removed comment
Is there a message printed to stdout or stderr that says something like "Output is redirected to file <xyz>, no further messages will appear here"? I think it would be good to have it, so that people are not surprised by this change in behaviour.
Otherwise, looks good.
-
reporter - changed status to open
- removed comment
Ok, my intention was a bit different than this, and my testing didn't catch this for some reason. I will revise the patch.
-
reporter - removed comment
What I intended was having Cactus write to a file and to the screen. However, after reading up on the matter a bit more that does not seem possible, at least not using the mechanism Cactus uses for redirection.
Cactus uses freopen, which essentially changes stdout and/or stderr to point to a file. There does not seem to be a way to have one input stream point to two outputs. One would need to write twice. This is problematic in this case, as I would imagine not everyone uses the CCTK_* wrappers, especially not for debugging. The current solution redirects, e.g., a printf too. Even worse - freopen is not (portably) reversible. Once redirected to a file there is no (portable) way to get it back to stdout.
One option I still see would be to redirect to a file, and having a second thread (created before MPI_Init, like the web server) constantly printing the contents of that file (like tail -f). This would not be ideal either though, because especially for crashes (one of the use-cases of this feature), users might 'miss' output.
Another possibility would indeed be a new parameter to do the normal redirection also on the root process, but one would need to know then that this run will be quite silent in the terminal...
Does anybody have a better idea? Any preferences?
-
- removed comment
If Cactus indeed only uses freopen to redirect stdout and stderr, then there may already be an issue with redirecting output from Fortran's WRITE statement which has not reason to use the C stdout and stderr streams I think (maybe new Fortran versions say newer than 2003 may do that. Would you know, Peter?).
In the case that Fortran code is not required to use stdout and stderr (but instead uses file ids 1 and 2) we can instead use the dup2 call in unistd.h (and fileno to get the file id of the redirection file from fopen).
-
reporter - changed status to open
- removed comment
I now added a message. I didn't want to over-engineer this issue, and certainly didn't want to rewrite all the redirection code. I just found it odd that the output of one process is missing when redirecting, which can be inconvenient. I now added a message to the request. The change can now be summarized by:
- also redirect stdout/stderr of process 0 if requested. This means that nothing is going "to the screen" anymore in that case.
- Add a message (before the redirection) that hints the user about this fact, and suggests using 'tail -f' as possible way to follow the output.
-
- removed comment
Regarding the questions about Fortran above, I add print* statements all the time to Fortran code when debugging and I haven't seen any issues with the redirection of stdout from Fortran code in Cactus, so it looks like freopen also affects Fortran routines later on in the execution. Usually Fortran uses file units 0, 5 and 6 for stderr, stdin and stdout, but this is not required by the standard. In Fortran 2003 there is a standard intrinsic module (iso_fortran_env) that contains the information for any given implementation.
-
reporter - changed status to open
- assigned issue to
- removed comment
removing "review" until there is a new patch.
-
reporter - changed status to open
- removed comment
I updated the pull-request, to leave -r[oe] as it is right now, but add -R[oe] to redirect output from all processes. In that case, a warning is output (before the direct happens) to warn the user that from then on likely nothing will be printed to the screen.
-
- removed comment
I am happy with adding a -R option. One minor issue: The implementation introduces magic numbers for
requested_stdXXX_redirection
(it distinguishes 0,1, >1). It may be better to either use an enum or #defines for this. Theif(requested_stdout_redirection)
kind of checks would then become (assuming the do-not-redirect value is called redirect_none)
if(requested_stdout_redirection != redirect_none)
-
- changed status to open
- removed comment
-
reporter - changed status to resolved
- removed comment
done, and merged in
-
- changed status to open
- removed comment
The patch actually removes the ''required'' redirection of stdout to /dev/null in the non-root ranks when no redirection to file is requested. This leads to output to stdout via printf etc to be duplicated. This affects eg the Cactus banner, but not CCTK_Info etc since those contain an explicit check for the rank I think. Anyhow, this should be fixed or the commit(s) need to be reverted.
-
- changed status to resolved
- removed comment
Fixed in git hash 301758e96c01d2442a4d62504593760a9f8d4b57 of the flesh.
-
- edited description
- changed status to closed
- Log in to comment