Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dump environment to stderr on job fail? #2150

Closed
hjoliver opened this issue Feb 8, 2017 · 5 comments
Closed

Dump environment to stderr on job fail? #2150

hjoliver opened this issue Feb 8, 2017 · 5 comments
Assignees
Labels
Milestone

Comments

@hjoliver
Copy link
Member

hjoliver commented Feb 8, 2017

If an error is trapped by the job script, or when running in debug mode, we could this before exiting.

env 1>&2

@cylc/core - any objections to this? The environment might occasionally have useful diagnostic info...

@hjoliver hjoliver added the small label Feb 8, 2017
@hjoliver hjoliver added this to the later milestone Feb 8, 2017
@matthewrmshin matthewrmshin self-assigned this Feb 9, 2017
@matthewrmshin
Copy link
Contributor

No objection, can be done as part of #2141 or as a follow up. However, I'd use printenv, for correctness.

From man printenv and man env:

  • printenv - print all or part of environment
  • env - run a program in a modified environment

@dpmatthews
Copy link
Contributor

I'm not a fan of this for normal use. At the moment, if you have a well written task which fails then hopefully you can take a look in job.err and expect to find a clear error message telling you what happened. With this change that message would then be followed by lots of extra output which would only be of very occasional use (probably more relevant when debugging a new suite rather than more generally).

@arjclark
Copy link
Contributor

I wouldn't want it in the main .out/.err files (pretty much for the reasons @dpmatthews gives above) but I don't think I'd massively object if it was in a .env file or something to that extent.

@matthewrmshin
Copy link
Contributor

I suppose we don't have to have this built-in. If users are worried about the environment, it should be relatively straightforward to stick a printenv command in pre-script or something? Or do we need a customisable on-error-script that gets called as part of the error trap?

@hjoliver
Copy link
Member Author

Good points all. BTW this was a suggestion from someone at BoM.

I like the idea of a custom on-error-script that gets called by the error trap. I think output from that should probably go to stderr, but if you put printenv in it then ... you get what you asked for.

@matthewrmshin matthewrmshin modified the milestones: soon, later Feb 13, 2017
@matthewrmshin matthewrmshin modified the milestones: next release, soon Feb 15, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants