Send Motion-user mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/motion-user
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Motion-user digest..."
Today's Topics:
1. Non-streaming camera and HTTP-Keepalive triggers deadlock in
camera thread (Tim Skopnik)
2. Re: Non-streaming camera and HTTP-Keepalive triggers deadlock
in camera thread (tosiara)
----------------------------------------------------------------------
Message: 1
Date: Thu, 23 Apr 2020 17:40:42 +0200
From: Tim Skopnik <[email protected]>
To: [email protected]
Subject: [Motion-user] Non-streaming camera and HTTP-Keepalive
triggers deadlock in camera thread
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi folks!
I have severe problems keeping motion connected to a few non-streaming
cameras using HTTP-keep-alive.
(and also w/o keepalive but i will post that under another subject)
Tried multiple versions (currently 4.3.0 and 4.3.1)
Fist problem occures when connecting to lighttpd as server for
still-images (jpg - _not_ mjpg):
1. As lighttpd does not send response-headers "Connection: Keep-alive"
on HTTP/1.1 request (not shure if it should do that as connection
keep-alive ist default in HTTP/1.1) motion shuts down keepalive after
the third GET-Request automatically even whon option netcam_keepalive is
"on". I think this is as unexpected for a reader of the logs as
unnecessary as the headers seem to be optional.
2. Is there _is_ a Connection: Keep-Alive"-response-header (other
Webserver, or manually added by setenv-module) the camera is connected
at first but after a while / when webserver closes the initially
kept-alive connection due to maximum request limit the camara thread
gets stuck reading the response headers and logging infinitively
... netcam_read_first_header: Error sending 'connect' request: Broken pipe
... Above message repeats 5000 times
It seems to me that netcam_connect? is responsible for verifying the
connection before headers are read and in case of keep-alive this method
is not called/the dead connection is not detected.
I was able to migitate this problem by adding
??????? netcam->keepalive_timeup = TRUE;
to
netcam_http.c :
??? /* Send the initial command to the camera. */
??? if (send(netcam->sock, netcam->connect_request,
???????????? strlen(netcam->connect_request), 0) < 0) {
??????? MOTION_LOG(ERR, TYPE_NETCAM, SHOW_ERRNO
??????????? ,_("Error senTTTTding 'connect' request"));
??????? // tps invalidate keepalive
??????? netcam->keepalive_timeup = TRUE;
??????? return -1;
??? }
which seems to solve the problem but i am not deep enough in this
software to verify if this is a good fix...
Any suggestions? Is this a known bug? Is the above a good fix?
Regards Tim Skopnik
--
[email protected], http://www.aptico.de/
aptico GmbH, Alter Hellweg 60, D-44379 Dortmund
fon: +49 231 185 85-20, fax: +49 231 185 85-25
Amtsgericht Dortmund: HRB 15084, Gesch?ftsf?hrer:
Dipl. Ing. Hartmut M?ller, Rudolf Slabe (MA),
Tim Skopnik
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 2
Date: Thu, 23 Apr 2020 19:21:21 +0300
From: tosiara <[email protected]>
To: Motion discussion list <[email protected]>
Subject: Re: [Motion-user] Non-streaming camera and HTTP-Keepalive
triggers deadlock in camera thread
Message-ID:
<cachtdwt1y9gox88lo4aiy7hecmfz6k0b_bkhx5mge7uyy-o...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Which netcam_url did you use in your config?
On Thu, Apr 23, 2020 at 7:04 PM Tim Skopnik <[email protected]> wrote:
> Hi folks!
>
> I have severe problems keeping motion connected to a few non-streaming
> cameras using HTTP-keep-alive.
> (and also w/o keepalive but i will post that under another subject)
>
> Tried multiple versions (currently 4.3.0 and 4.3.1)
>
> Fist problem occures when connecting to lighttpd as server for
> still-images (jpg - _not_ mjpg):
>
> 1. As lighttpd does not send response-headers "Connection: Keep-alive" on
> HTTP/1.1 request (not shure if it should do that as connection keep-alive
> ist default in HTTP/1.1) motion shuts down keepalive after the third
> GET-Request automatically even whon option netcam_keepalive is "on". I
> think this is as unexpected for a reader of the logs as unnecessary as the
> headers seem to be optional.
>
> 2. Is there _is_ a Connection: Keep-Alive"-response-header (other
> Webserver, or manually added by setenv-module) the camera is connected at
> first but after a while / when webserver closes the initially kept-alive
> connection due to maximum request limit the camara thread gets stuck
> reading the response headers and logging infinitively
>
> ... netcam_read_first_header: Error sending 'connect' request: Broken pipe
> ... Above message repeats 5000 times
>
> It seems to me that netcam_connect is responsible for verifying the
> connection before headers are read and in case of keep-alive this method is
> not called/the dead connection is not detected.
>
> I was able to migitate this problem by adding
>
> netcam->keepalive_timeup = TRUE;
>
> to
>
> netcam_http.c :
>
> /* Send the initial command to the camera. */
> if (send(netcam->sock, netcam->connect_request,
> strlen(netcam->connect_request), 0) < 0) {
> MOTION_LOG(ERR, TYPE_NETCAM, SHOW_ERRNO
> ,_("Error senTTTTding 'connect' request"));
> // tps invalidate keepalive
> netcam->keepalive_timeup = TRUE;
> return -1;
>
> }
>
> which seems to solve the problem but i am not deep enough in this software
> to verify if this is a good fix...
>
> Any suggestions? Is this a known bug? Is the above a good fix?
>
> Regards Tim Skopnik
>
>
> -- [email protected], http://www.aptico.de/
> aptico GmbH, Alter Hellweg 60, D-44379 Dortmund
> fon: +49 231 185 85-20, fax: +49 231 185 85-25
> Amtsgericht Dortmund: HRB 15084, Gesch?ftsf?hrer:
> Dipl. Ing. Hartmut M?ller, Rudolf Slabe (MA),
> Tim Skopnik
>
> _______________________________________________
> Motion-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/motion-user
> https://motion-project.github.io/
>
> Unsubscribe: https://lists.sourceforge.net/lists/options/motion-user
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
------------------------------
Subject: Digest Footer
_______________________________________________
Motion-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/motion-user
------------------------------
End of Motion-user Digest, Vol 166, Issue 25
********************************************
