Debug Logging

[Cyberprog]

Hi All,

Could someone advise exactly which log files are generated when Debug Logging is turned on? I'm investigating issues here with a number of Raspberry PI systems where they go dark (black screen) and stop responding on the web interface (though usually the SSH is OK). A reboot seems to solve things, but I'm not getting anywhere figuring out why things have stopped working!

Does screenly use a watchdog or anything similar at present to check and see if things are working properly and restart things automatically if they're not?

Cheers!

Alex.

[vpetersson]

Could someone advise exactly which log files are generated when Debug Logging is turned on?

There are no additional log files. It's just more debugging that is being added to the existing ones.

Does screenly use a watchdog or anything similar at present to check and see if things are
working properly and restart things automatically if they're not?

There are a few mechanisms in place for this. They are not watchdogs per se, but they work in a similar fashion. xloader.sh for instance wraps viewer.py in an infinite loop, so if it crashes, it will automatically get respawned.

The server module is managed by supervisord which has a built-in monitoring tool.

[Cyberprog]

Ah right, can you confirm for me the logs in question please Victor?
/tmp/screenly_viewer.log
various in /var/log/supervisor
I'm aware the one in /tmp/ will get replaced on boot - does a copy of this get saved elsewhere?
We've seen issues caused by massive (2+mb Jpeg's) causing the whole system to come to it's knees as well, this is with Class 10 SD cards btw. I wonder if more checks could be made of files as they're uploaded to prevent this sort of thing?
Screenly is a excellent system, I've found nothing better for what it does, but we seem to be plagued with issues atm that I'm unable to get to the bottom of conclusively. Sometimes swapping SD's solves problems (and I have seen issues where the SD is knackered) but not always...

[vpetersson]

can you confirm for me the logs in question please

Yes, it's /tmp/screenly.log* for Screenly itself, as well as /var/log/supervisor/*.log

We've seen issues caused by massive (2+mb Jpeg's) causing the whole system to come to it's
knees as well, this is with Class 10 SD cards btw. I wonder if more checks could be made of
files as they're uploaded to prevent this sort of thing?

I can see that rendering a 2MB Jpeg could certainly push the RasPi hard. Try with a Ras Pi 2 and see if that makes a difference.

[Cyberprog]

I took a slightly more direct approach and LARTed the graphics guy who made & uploaded them. Trying to keep them <256kb now. May be worth adding a sanity check to the system though for a >1mb jpeg on Ras Pi 1 to say "Are you sure you want to do this?"

[vpetersson]

Perhaps, but i think it's mostly an edge case.

[TeacherZ]

I am running into a similar issue on a raspberry Pi Zero that otherwise runs nicely. I can't find the log files though. Have they been moved in the current version? I have the 1-19-2018 version.

[vpetersson]

@TeacherZ - We've chanced a lot of things since this ticket. Logging is now managed through systemd. You can get logs by running journalctl.

[ddn]

@TeacherZ @vpetersson I wonder if this is not a coincidence. I just landed here because a previously rock-solid stable recently updated pi2 now dies almost daily, and a brand new install on a pi3 is reverting to the IP display screen on an almost daily basis. I don't know exactly what version the pi2 was running of OSE because something in ansible was silently preventing it from updating for a long time.

I wish I could offer more information at this point but I just started investigating, and unfortunately they are both remote. However when the pi2 dies the screen "flickers" and it's completely dead to the network, no ping, no ssh.

[vpetersson]

ping @antonmolodykh

[antonmolodykh]

Ok, I'll let you know when I fix it. Thanks, guys.

[antonmolodykh]

@TeacherZ please run the update from master branch, I made the fix. let me know if there are problems again, thank you.