Software locking up when scrolling through EPG

[adm]

I can't see why you lose the current debug log file when you power off.

I'm not losing the debug file when I power off normally. It's just I cannot power off normally on the lock-up as NONE of the remote buttons work, including the power button. If I kill the box by switching off the mains as a result of a lockup I get no debug logs and no crash logs.

[birdman]

I'd also try telnet init 4 to stop enigma and init 3 to restart it, rather than powering off at the mains.

If enigma2 is really looping then init 4 might not stop it. You might need:

• init 4
• killall enigma2 (if there is still an enigma2 process running - look at ps -ef output)
• killall -9 enigma2 (if there is still an enigma2 process running)
• init 3

[birdman]

If I kill the box by switching off the mains as a result of a lockup I get no debug logs and no crash logs.

That makes no sense.
Well, you'll never get a crash log as you never have a crash, but that shouldn't make debug logs disappear. Although in #9 you seem to be saying that you don't get any debug log started at the next start-up, which is the bit that is very odd.

[adm]

Edit: I've just had another lock-up when scrolling through the EPG (5.1.022)

After lock-up telnet into box and init 4. Video/audio still worked still locked up (as expected)
As a check to see if telenet still working a df -Th gave the correct filesystem information
An init 3 resulted in no futher prompts in a windows 10 telnet command window. Box still in the lock-up condition, video and audio still working

Telnetted to the box again and init 6 which rebooted the box
Scrolling through the EPG now working again

The only two debug logs with timestamps associated with the problem occuring and the telnet commands are attached. There are no crash logs.

logs _2.zip

[adm]

That makes no sense.
Well, you'll never get a crash log as you never have a crash, but that shouldn't make debug logs disappear. Although in #9 you seem to be saying that you don't get any debug log started at the next start-up, which is the bit that is very odd.

Just to confirm
5.1.022 via software update
I get a debug log if I put my box into deep standby
I do not get a debug log (or crash log) if the system hangs and I have to kill via the mains switch.
I do not get a debug log on the box starting up as a result of coming out of deep standby or as a result of being switch back on from the mains

I get no crash logs.

The existing logs I have in the log folder do not get deleted except when i manually delete them.

Reverting back to 5.1.021 which was also a software update
I only get a debug log for a normal shutdown. There is no startup debug log

Couch flashing 5.1.022 with a settings restore from 021
I only get a debug log for a normal shutdown. There is no startup debug log

Changing the log location to /media/hdd/logs and a reboot
No change. I get a debug log for a normal shutdown. There is no startup debug log

[ccs]

I'm not losing the debug file when I power off normally. It's just I cannot power off normally on the lock-up as NONE of the remote buttons work, including the power button. If I kill the box by switching off the mains as a result of a lockup I get no debug logs and no crash logs.

That's what I was saying in my post.

[ccs]

When I was messing about with nas mounts last week, I have the faintest recollection of debug logs being switched off when I was sure they were on.

Have you noticed anything similar?

[adm]

When I was messing about with nas mounts last week, I have the faintest recollection of debug logs being switched off when I was sure they were on.

Have you noticed anything similar?

I was also messing around with the same and wondered if this was the cause of the missing debug messages (perhaps a timing issue when accessing external equipment)
During the time I was messing around with different settings I deleted my external disk mount and rebooted the box - it made no difference.
When deleting the mount the box crashed (finger trouble) and generated 3 off crash messages so the box is still capable of generating these messages when necessary.
I also deleted/removed a MP3 browswer plugin that I installed last week and rebooted - no difference.

[birdman]

I get a debug log if I put my box into deep standby
I do not get a debug log (or crash log) if the system hangs and I have to kill via the mains switch.
I do not get a debug log on the box starting up as a result of coming out of deep standby or as a result of being switch back on from the mains

That's the bit which makes no sense.
The log is opened by the script which starts enigma2. So if it's being opened it will be there when the system hangs.

I get no crash logs.

It's not crashing,so that's to be expected.

Reverting back to 5.1.021 which was also a software update
I only get a debug log for a normal shutdown. There is no startup debug log

As I said, it is opened (if at all) at enigma2 start-up. It doesn't (and can't) "just appear" at shutdown.

[adm]

That's the bit which makes no sense.
The log is opened by the script which starts enigma2. So if it's being opened it will be there when the system hangs.

It's not crashing,so that's to be expected.

As I said, it is opened (if at all) at enigma2 start-up. It doesn't (and can't) "just appear" at shutdown.

Perhaps I'm misunderstanding.

As I read you post...

On box start-up a log is started which presumably remains in RAM. So when does this log first get written to the log folder.
1) As and when required on a continuous basis while the box is on?
2) When the amount of data in the RAM reaches a threshold value?
3) Only as part of the shutdown process?

If 3 then this is what I’m seeing - one debug log file per on to off operation EXCEPT no file is written when I have to kill the box by an abrupt mains diconnection.

It doesn't "just appear" at shutdown
The file is in the log folder the next time the box is switched on with a time stamp matching the time when the box was last switched off.

So, all debug files are correcrtly generated if the box closes down normally.
When the box hangs debug info cannot be written because the box cannot be shut down in a normal way

[birdman]

Perhaps I'm misunderstanding.

Hence the questioning....to avoid any misunderstanding both ways.

On box start-up a log is started which presumably remains in RAM.

No. It gets written to the file-system as each entry arrives. That's why you can read the latest entries in the log when the process is running.

...one debug log file per on to off operation EXCEPT no file is written when I have to kill the box by an abrupt mains diconnection.

No. See above. You can, if you wish, tail -f the log to see the entries as they arrive whilst the process is running.

The file is in the log folder the next time the box is switched on with a time stamp matching the time when the box was last switched off.

That's correct. If you've powered off at the mains the log should still be there, but its timestamp might not be correct. It should, however, be the last-but-one log (another one will have been started by the time you get to look for it).

So, all debug files are correctly generated if the box closes down normally.

They are written to disk as the entries arrive. There will be memory buffering, but that would just mean you might not get the last few lines: the file should still be there - it was created when enigma2 started.

[adm]

Hence the questioning....to avoid any misunderstanding both ways.

[snip]

Thanks for the explanation.

What has been confusing me is the timestamp applied to the debug file.

I telnet into the box and at 1:55am issue a init 4 command and then go to the logs folder and delete all the logs. At 2:06am I issue a init 3 command I get a new debug log file with a time stamp of 2:06. The time stamp starting this way is the current correct time. This confirms to me that a file is created on start-up.

BUT….

I now put my box into deep standby at 2:09am and then switch it back on at 2:15am. On immediately checking I now see another debug log with a time stamp of 2:09 and NOT 2:15 as expected. The time stamp applied to this file is last time the box was switched off and NOT the time that the box was switched back on again. The file and name may have been created as the box switched on but the time stamp hasn’t come from the current time – it has come from a historic record which may be minutes or hours in the past depend on how long the box has been switched off.

I’ve been assuming that the time stamp on the file reflected reality hence when switching the box off normally the file was created on switch off, as per the time stamp applied to the file.

[ccs]

Where are you getting the time from, a time server or the current mux/transponder?

[adm]

The file and name may have been created as the box switched on but the time stamp hasn’t come from the current time – it has come from a historic record

Just to confirm. I switched the box into deepstandby at 3:00am and next switched the box on at 9:27am. The timestamp on the most recent entry in the log folder is 3:00:44.

Edit: and first time into the graphocal EPG and a lock up. The lock up occured immediately on the bouquet/epg appearing

Telnet to box, init 4 then init 6 and here is the debug file
The file with the timestamp of 3-00-44 was the one active when the lock-up occured
The file with the timestamp of 9-42-19 is the file start after the init4, init 6 reboot

logs_3.zip



Edit 2
Could this be an extreme symptom of something I have seen on a very odd occasion in many builds? I tend to change channels by going to the graphical EPG and scrolling up/down to find something else to watch. Sometimes when pressing, say, the down button multiple times the box doesn’t respond to the key presses immediately. It waits for maybe one or two seconds and then responds to all previous key presses and the program 5 down from the start position is highlighted.
In the case of the lock-up this delay is extended to forever (or at least > 5 minutes)

[ccs]

I reckon the last shutdown time is used very early in the boot process.

Very long thread here which may confirm.....

http://www.world-of-satellite.com/sh...t=timer+server