Eye kills itself #62
Comments
|
seems, it happen when you process restart or stop and celluloid kill your long running(sleeping) check. So there is no problem, as it seems. |
|
There is no more log after this line - that is the last log in the file, here is the log before this line and after restarting eye the next day (look at the date stamp): |
|
Something strange, looks like celluloid bug. |
|
with ffmpeg there's -stimeout 5000000 - so it should timeout within 5 seconds. With @rtsp_client.describe - I'm not 100%, but if I try to access an IP that doesn't respond, it times out within a couple of seconds. The entire log file is 3GB, heh - I will email you the config and a fair chunk before the freeze. |
|
send last day of log, or something |
|
Sent, looks like the system rebooted but still not sure why eye didn't start correctly and stopped responding shortly after starting. |
|
After this error happen, process eye is running or not? In log, looks like someone just kills eye. (send term signal or something) Can you find eye self-pid in log? Which starts with "starting Eye ... What ruby are you using? 2014-05-30 17:02 GMT+04:00 xanview notifications@github.com:
|
|
I'm using ruby 2.1.1p76 (2014-02-24 revision 45161) It seems weird anything would try to kill eye since nobody was connected to the server when it happened. I will try to reproduce by rebooting the server until it happens again and report back. |
|
i add to master log signals, maybe this is helps c5e97bf |
|
Also enable |
|
I had this happen again recently and ps aux | grep eye doesn't show eye running at all and nothing in the logs to help identify what happened. This time on a server with an uptime of 80 days and it happened 15 days ago so limited log availability (didn't notice this because the processes were still running) :( I will update eye on all the servers to the latest version today and report if/as soon as it re-occurs! |
|
i think this is related to #67, when eye load pid from pid_file of one of eye-self threads (lwp), and then kill itself, in 0.6.2 i try to fix it. |
|
try 0.6.2.pre i think this should be fixed. |
|
Pushing to all servers, will re-open if this happens again! |
|
i reproduce it, this is a crazy case, when process die, and in 5s there is up new process with the same pid (eye lwp), so eye even not seen that process die, and monitor that wrong new process (self lwp), and then kill itself. Need to check pid + identity(name or start_time) for that pid. I think i fix it in 0.7. |
|
Fantastic :) - I like the idea of checking both the PID and the start time - and possibly the name too, I mean why not, will make sure there is no chance that the wrong PID is being monitored/controller. Looking forward to 0.7, great work! |
|
Hey :) - I had that happen again :( - in fact it happens from time to time (with the latest version), but this time a client complained :( Boom, no more eye :( - happened after an unclean reboot, so I'm guessing eye assumed it is still running and was looking for processes based on PID only :( Any update on this? |
|
there is commit for this ea964b6, but it makes eye 2 more times using cpu, need to decrease it. |
|
Thank you for working on this :) |
|
this should be fully fixed in 0.8 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have this check:
It works most of the time, however sometimes, I get this in eye.log and it stops monitoring all processes:
The formatted output looks like this:
Any ideas why it happened and how to prevent this from happening?
The text was updated successfully, but these errors were encountered: