Conversation
There was a problem hiding this comment.
Cool! Thanks @jamesalbert ! Sorry for the long delay.
This is great! I wasn't sure if anyone was really using this but I take it you are?
Before merge we just need to be certain everything's working, and the test log should help but might require a little more poking to be sure.
I'm a little short on time but let me give a little explanation on the test log and maybe you can look and confirm: The test log is representing exactly what each process is doing. Remember there are two procdog processes involved, the client and the monitor (each logs a prefix saying which). The challenge is those are being sent to the same output stream and the interleaving of them now looks a lot different. If the overall sequence is right it's strongly indicative everything is working.
One approach might be we should write client and monitor logs before and after to different files, and check those in instead of the full unified log. Or worst case grepping this into two files. Or something like that, as long as we're able to confirm each process is doing the right thing.
Hope that's helpful! Let me know how it goes and I'll look a bit more after that.
| procdog (_PID_): debug: command-line options: {'command': 'sleep 5', 'health_command': 'true'} | ||
| procdog (_PID_): debug: combined options: Options(command='sleep 5', health_command='true', health_count=5, health_delay=1.0, ensure_healthy=False, dir=None, stdin=None, stdout=None, stderr=None, append=False, linger=3.0, strict=False, shell=False) | ||
| procdog (_PID_): debug: client: acquired lock: True: /var/tmp/procdog.long.lock | ||
| procdog (_PID_): debug: command-line options: {'command': 'sleep 5', 'health_command': 'true'} |
There was a problem hiding this comment.
Not clear to me why this is happening twice. It's odd as the command was invoked once above.
| procdog (_PID_): debug: combined options: Options(command='sleep 5', health_command='true', health_count=5, health_delay=1.0, ensure_healthy=False, dir=None, stdin=None, stdout=None, stderr=None, append=False, linger=3.0, strict=False, shell=False) | ||
| procdog (_PID_): debug: client: acquired lock: True: /var/tmp/procdog.long.lock | ||
| procdog (_PID_): debug: client: wait: checking for connect... | ||
| procdog (_PID_): monitor: starting with Options(command='sleep 5', health_command='true', health_count=5, health_delay=1.0, ensure_healthy=False, dir='/tmp/procdog-tests', stdin=None, stdout=None, stderr=None, append=False, linger=3.0, strict=False, shell=False) |
There was a problem hiding this comment.
The fact that this is now missing means the monitor started later.
| exited, returncode=-15 | ||
| (got expected error: status 5) | ||
| sleep 4 | ||
| procdog (_PID_): debug: command-line options: {'command': 'sleep 5', 'health_command': 'true'} |
There was a problem hiding this comment.
Now the monitor is starting. So it's good, just delayed. But unsure why that'd happen. With changing to 3 are we getting some connection difference? Or something different with your machine.
If the actual time difference is really small, it's no big deal, but we should check.
We'd still want to verify both client and monitor are going through the same motions, though.
2 participants
I started with calling 2to3 on
procdogand smoothed out the rest with trial and error. The basic start, status, and stop flow seems to work. I'm happy to make any desired changes before merge. This would also allow for #1 to be closededit: not sure what the test log diff is telling me :) hopefully good things