web gui constantly cycles to permission denied

[rockedge]

I am not sure exactly why but the CPU load is really high and with only 1 camera and the web GUI is constantly cycling to a permission denied page as seen below. The page will load again after a refresh then display this page. Camera streams for 20 seconds and crashes. Log is stuffed with errors.

Puppy Linux Bionic 18.05 kernel 4.17.9
ZM 1.32

Screenshot.png (7.5 KiB) Viewed 6990 times

[gsaindon]

I report the same problem. To view the live stream we have to use the "Montage review".

[rockedge]

I am not getting the page now but my streams from the console from individual monitors will work 10 seconds then disappear and the web gui monitor page constantly refreshes with no stream view but the entire div flutters back and worth finally jumps back to a clean stream for 10 second or less and repeats the cycle.

as to why the permission denied page stopped showing up or why it did in the first place is a complete mystery.

but the cycling and stream crashing constantly is making ZM unusable. The recorded events seem to be clean and uninterrupted

this is occurring on Ubuntu/Debian based Puppy Linux Xenial, Bionic 32bit and 64 bit and XenialDog which is a minimum Ubuntu made to look like a Puppy Linux but is really just a very light Ubuntu and all versions through 1.31.1 worked great and reliably with it.

[gsaindon]

Hi, I installed the latest updates 1.32.0~20180921105049-xenial and the problem is still present.

[jedix]

I am also seeing this issue

[jggg]

And me, with last version from master.

[rockedge]

I still have not found the source of this problem. Seems to occur during a page refresh cycle. with this url appearing during a page refresh occurring during viewing of a monitor stream, changing the url from

Code: Select all

http://localhost/zm/index.php?view=watch&mid=1

to

Code: Select all

http://localhost/zm/index.php?view=watch

then the permission denied page appears.

[doubleosix]

I now have the same issue

[iconnor]

I think if we check the console log we would find javascript errors. So check there. When there is an error doing a background ajax call (which is usually due to timed out auth) it refreshes the page in an attempt to get a new auth token.

The short auth timeout problem is normally due to a discrepancy between the timezone in the db (aka the system timezone) and the timezone set in the php.ini.

[knight-of-ni]

This thread contains one person who has documented the issue and three "me too's" for a total of four people.
However, Isaac's post, which suggested were to look for additional data, has gone unanswered.

Guys, we don't have a magic stick we just wave to make the problem all better. This is going to take good old fashion back-and-forth interaction between us and those that are experiencing the issue.

Please read Isaac's post and respond accordingly. Not understanding what he is asking is a completely fair question, so feel free to ask if something does not make sense.

We are on the verge of a 1.32.1 release, but if we don't get any followup regarding this particular issue then it simply won't be resolved.... whatever the fix ends up being.

[iconnor]

Here's some commands from a terminal that might shed some light in regards to the timezone
cat /etc/timezone
grep timezone /etc/php/*/apache2/php.ini

[jedix]

Sorry for the late reply.

No javascript errrs that I see in my logs.

Code: Select all

{/tmp} $ date
Sat Sep 29 14:34:58 EDT 201
{/tmp} $ cat /etc/timezone
America/New_York
{/tmp} $ grep timezone /etc/php/*/apache2/php.ini
/etc/php/7.0/apache2/php.ini:; Defines the default timezone used by the date functions
/etc/php/7.0/apache2/php.ini:; http://php.net/date.timezone
/etc/php/7.0/apache2/php.ini:date.timezone = America/Toronto
/etc/php/7.2/apache2/php.ini:; Defines the default timezone used by the date functions
/etc/php/7.2/apache2/php.ini:; http://php.net/date.timezone
/etc/php/7.2/apache2/php.ini:;date.timezone =
{/tmp} $

Hope this helps.

[iconnor]

Interesting. America/New York should be the same as America/Toronto, so I think this means that the timezone issue is not the problem.

One thing: the javascript console clears itself when the page refreshes. There is a preserve log checkbox, which will prevent this. THere may be javascript errors that are disappearing.

other places to look: make sure debug is on in options
LOG_DEBUG checked
LOG_LEVEL_FILE is Debug
LOG_DEBUG_TARGET is empty

Then check /var/log/zm/web_php.log

hopefully something useful will be listed.

[jedix]

That file doesn't exist.

I get a whole lot of zm_debug.log.<pid> (I assume the pid)

The only ERR/WAR message I get is:

Code: Select all

{zm} $ grep ERR *
zm_debug.log.20626:09/29/18 21:20:56.832867 web_php[20626].ERR [Socket /var/run/zm/zms-152789s.sock does not exist.  This file is created by zms, and since it does not exist, either zms did not run, or zms exited early.  Please check your zms logs and ensure that CGI is enabled in apache and check that the PATH_ZMS is set correctly.  Make sure that ZM is actually recording.  If you are trying to view a live stream and the capture process (zmc) is not running then zms will exit. Please go to http://zoneminder.readthedocs.io/en/latest/faq.html#why-can-t-i-see-streamed-images-when-i-can-see-stills-in-the-zone-window-etc for more information.] at /usr/share/zoneminder/www/includes/functions.php line 2042
zm_debug.log.20626:09/29/18 21:20:56.871583 web_js[20626].ERR [getStreamCmdResponse stream error: Socket /var/run/zm/zms-152789s.sock does not exist.  This file is created by zms, and since it does not exist, either zms did not run, or zms exited early.  Please check your zms logs and ensure that CGI is enabled in apache and check that the PATH_ZMS is set correctly.  Make sure that ZM is actually recording.  If you are trying to view a live stream and the capture process (zmc) is not running then zms will exit. Please go to http://zoneminder.readthedocs.io/en/latest/faq.html#why-can-t-i-see-streamed-images-when-i-can-see-stills-in-the-zone-window-etc for more information. - checkStreamForErrors()] at ?view=watch line 
zm_debug.log.20962:09/29/18 21:20:33.008045 zms_m2[20962].ERR-zm_monitorstream.cpp/423 [Frame send time 77 msec too slow, throttling maxfps to 20.00]
zm_debug.log.20962:09/29/18 21:20:41.412761 zms_m2[20962].ERR-zm_monitorstream.cpp/423 [Frame send time 343 msec too slow, throttling maxfps to 13.33]
{zm} $ grep WAR *
zm_debug.log.19426:09/29/18 21:20:56.737939 zms_m2[19426].WAR-zm_monitorstream.cpp/410 [Unable to send stream frame: Broken pipe]
zm_debug.log.20184:09/29/18 21:17:01.801615 zms_m2[20184].WAR-zm_monitorstream.cpp/410 [Unable to send stream frame: Broken pipe]
zm_debug.log.21070:09/29/18 21:27:35.345195 zms_m2[21070].WAR-zm_monitorstream.cpp/410 [Unable to send stream frame: Broken pipe]
{zm} $ 

Neither of these seem to be anything to do with the access issue. Is there soemthing I'm missing or something better to grep?

[bbunge]

For those who have reported this issue are you running a GUI/desktop version of Bionic?
What is your hardware configuration?
Are you trying to run in a container or VM?
Thanks, I would like to duplicate the issue...

bb