Motion - Bug Report 2005x 11x 22x 172816

BUG: Webcam interface crashes after 24-48 hours.

im running motion on kernel 2.4 debian box. the old version worked ok. with the new version the webcam interface disappears after 24-48 hours usually after my cron process does a chattr +i to the motion executable and the conf/ files. it seems that motion doesnt like the files becoming readonly without any warning. maybe there should be a readonly file system option to motion ?? i need it readonly since i periodically delete the directory to get rid of excess snapshots and the only thing saving motion from being rm'd is the chattr readonly command.

Test case

run motion 24-48 hours. chattr all the motion conf/ and executable files and wait another 24-48 should crash well before then.


Motion version: 3.2.4 Snap5
ffmpeg version: ? - CVS, build 3211265 - the one linked to from this site
Shared libraries: ffmpeg, curl, xmlrpc
Server OS: fedora core3, kernel 2.6.12-1.1381

-- TWikiGuest - 22 Nov 2005

Follow up

Is there any message in syslog ?

Btw , you don't need curl either xmlrcp for motion 3.2.3.

-- AngelCarpintero - 23 Nov 2005

I have seen that happen too, seem to me that it happen when making the timelapse file shift at midnight. Motion runs for 3-4 days but then it goes wrong in as I can see something with FFMpeg, log only shows:

Nov 28 00:00:00 0x535b2f78 motion: [4] avcodec_open - could not open codec: Connection reset by peer

Timelapse files for cam 1-3 (of 4) was created but no file for cam4 - sometimes it's at one of the other cams it goes wrong. I have seen Motion die with both 3.2.3, 3.2.4 snap4 and snap5 - really not sure what the log says eccept for this last one.

-- TWikiGuest - 30 Nov 2005

Could you attach your motion.conf and config files ? maybe something is wrong in your timelapse. According with the syslog message could be a problem reading / wrinting because these function can set errno with ECONNRESET, but i don't see why it can happen "sometimes" as you said.

-- AngelCarpintero - 01 Dec 2005

Follow up

Here they are, as you can see Timelapse setting is 0 i am setting that via the http interface on the 'global' 0 thread. the setting is 300 in daytime and 1200 when it's dark outside. at the time writing Motion has running ok since 28/11 where the log entry is from, motion was startet again at 01:36 that night when i found out motion was gone.

-- TWikiGuest - 01 Dec 2005
Tonight it did it again this time motion has run since 28 nov. again the only thing in log from motion is:

Dec 9 00:00:00 0x535b2f78 motion: [4] avcodec_open - could not open codec: Connection reset by peer

But this time it was followed by these lines:
Dec  9 00:00:00 0x535b2f78 kernel: RULE 5 -- DENY IN= OUT=eth1 SRC= DST= LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=61606 DF PROTO=TCP SPT=51353 DPT=80 WINDOW=6432 RES=0x00 ACK FIN URGP=0
Dec  9 00:00:01 0x535b2f78 kernel: RULE 5 -- DENY IN= OUT=eth1 SRC= DST= LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=61608 DF PROTO=TCP SPT=51353 DPT=80 WINDOW=6432 RES=0x00 ACK PSH FIN URGP=0

But that is cam3/thread3 and not 4 so i think that it happens as a result of motion died just before.

-- TWikiGuest - 09 Dec 2005

There are two bugs in this report. Not good for any of them. Only thing common is the crashing.

The first bug - Motion dies when you change attribute on the running attribute and delete files in the same directory that Motion resides in. Well. That is a silly thing to do in the first place.

Save your files somewhere else than where Motion executables and configs are located.

And make sure you never delete files that Motion keep open.

So that bug report is rejected.

The other bug is more difficult to understand. A few bugs were fixed between 3.2.4_snap5 and 3.2.4 so maybe it is gone now.

If not I would check which ffmpeg version I have. And from the last error message it also seems that you may have a problem with iptables.

Try Search Google for kernel: RULE 5 -- DENY IN= OUT=eth1

-- KennethLavrsen - 18 Dec 2005

Hi it's me with 'the other bug' smile

Just want to say that i still have the problem now and then also on 3.2.4.

The thing with the firewall was only seen that single time so i don't think it has to do with the problem.

A shot summary would be that once in a while at 00.00 one or more threads die without much info i the logs.

The other day I made an upgrade to FC4 and wil see what happens now.

When FC5 final is released i will go to that on new 64bit hardware and hope not to see this problem anymore.

-- TWikiGuest - 02 Mar 2006

Now I had one more of this:
Apr 28 00:00:00 83 motion: [2] avcodec_open - could not open codec: Broken pipe
Apr 28 00:00:00 83 motion: [2] ffopen_open error creating file [/home/klaus/motion/20060428-tl-cam2.mpg]: Broken pipe
Apr 28 00:00:01 83 motion: [2] netcam camera handler: finish set, exiting
The file is never createt and like PeterS is writing in I also still believe that it is something about ffmpeg that is the reason to this error.

If there is any sugestions of what to do to get to the root of this error I'll be happy to try it out.

What I have no idea about is why it makes the whole thread die and I would really like to have implementet. smile

-- TheOtherBug - 03 May 2006

Been traveling last week. Will try and follow up later this week.

-- KennethLavrsen - 03 May 2006

Please try the patch I generated that adds the code to handle error messages coming from ffmpeg/avcodec. That may likely be causing the crash. I'm interested to see what gets logged besides the "errno" value (which I think is a misnomer, or is misleading.)

-- PeterS - 22 May 2006

Fix record

BugReportForm edit

TopicTitle Webcam interface crashes after 24-48 hours.
BugStatus Monitored
AssignedBugTo KennethLavrsen
SubmittedBy TWikiGuest
I Attachment Action Size Date Who Comment
cam1.confconf cam1.conf manage 5 K 01 Dec 2005 - 12:43 UnknownUser cam1-3 identical eccept for Cam IP / Webcam port
cam4.confconf cam4.conf manage 5 K 01 Dec 2005 - 12:44 UnknownUser like cam1-3 eccept Url for stream
motion.confconf motion.conf manage 7 K 01 Dec 2005 - 12:44 UnknownUser  
Topic revision: r11 - 22 May 2006, PeterS
Copyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Please do not email Kenneth for support questions (read why). Use the Support Requests page or join the Mailing List.
This website only use harmless session cookies. See Cookie Policy for details. By using this website you accept the use of these cookies.