1. Einstein Toolkit Avatar Einstein Toolkit
  2. Einstein Toolkit
  3. tickets
  4. Issues

redirect stdout and stderr of all processes if requested (also of the root process)

Issue #1704 closed
Frank Löffler created an issue

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)

  2. Erik Schnetter
    • 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?

  3. Frank Löffler reporter
    • removed comment

    It is also written to files for process 0. The patch only removes the "if (myproc)" statement. No new option.

  4. Erik Schnetter
    • 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.

  5. Frank Löffler 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.

  6. Frank Löffler 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?

  7. Roland Haas
    • 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).

  8. Frank Löffler 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.
  9. Peter Diener
    • 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.

  11. Frank Löffler 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.

  12. Roland Haas
    • 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. The

    if(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)
  15. Roland Haas
    • 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.

  18. Log in to comment
Assignee
Type
enhancement
Priority
minor
Status
closed
Component
Cactus
Milestone
–
Version
development version
Votes
0
Watchers
0
Jira Software: the preferred issue tracker for Bitbucket. Join the team!