better error messages when a logging process can't start
tcrayford opened this issue · comments
When you're starting a logging process, but it quits for some reason (e.g. you gave it bad configuration), it'd be super nice if angel said what it was trying to run that failed, and which job it belonged to.
Example config:
watch-date {
exec = "watch date"
logger = "sh -c 'echo \'failed\' && exit 1'"
}
watch-date2 {
exec = "watch date"
logger = "tee -a /tmp/watchlog"
}
when running this config, angel will quit out, with failed printed. But it won't tell you that watch-date was the cause of the failure, as opposed to watch-date2. This gets painful when you have even moderately sized configuration files (at time of writing, mine is at 118 lines).
Take a look at that branch and give it a spin. I couldn't exactly reproduce your issue. In the case where the logging process terminates early, before it was just being too quiet because the logging process is not tied to the monitored process. I augmented this logging so that the log process is annotated separately from the monitored process.
I'm not sure if I've missed the mark on this solution, but I think its a good idea either way. If I have missed the mark, could you give me an example of the error you see?
That seems to do the job. It also seems to have fixed another issue, which is that if the logging process stopped for whatever reason, the main app would be left running. Various vms (the jvm in particular) will completely block threads if the process that was reading from stdout was killed, which sucks.
Hmm. Are you sure it actually solved that issue? If you look at the code, the only thing I changed was around logging. It forks off a thread with the log process that logs, waits for it to finish, then logs that its done. That shouldn't have affected the semantics of what happens to the main app. AFAIK the main app continues to run if the logger crashes (unless something in the main app's code explodes when it cant write to stdout anymore?)
Merged in master.