mirror of
https://github.com/motioneye-project/motioneye.git
synced 2026-03-02 22:57:06 -05:00
ME PC hangs #2600
Labels
No labels
Android app
Arch Linux
CI/CD
CSS
FreeBSD
HTML/HTTP
Home Assistant addon
JavaScript
Python
Raspberry Pi
Stale No Activity 60 Days
bug
code format
dependencies
dev branch
docker
documentation
duplicate
enhancement
feature
help wanted
i18n/l10n
invalid
legacy motionEye
meta
motion
motionEyeOS
notourproblem
python update
question
question
security
troubleshooting
wontfix
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/motioneye#2600
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @macdroid53 on GitHub (Dec 18, 2024).
I'm trouble shooting an issue where the machine just hangs.
The hang appears random, but always after hour of up time. (Typically, 12 or more, sometimes a couple days.)
The system log shows this:
Dec 17 07:03:00 Motioneye3 kernel: microcode: microcode updated early to revision 0x24000026, date = 2023-09-26
Dec 17 07:03:00 Motioneye3 kernel: Linux version 6.1.0-28-amd64 (xxx) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.119-1 (2024-11-22)
Dec 17 07:03:00 Motioneye3 kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-28-amd64 root=UUID=fa28c875-7a8c-4122-aec5-369e16487c2d ro resume=UUID=975f9104-e799-4b4c-be06-680c969eba3c
Dec 17 07:03:00 Motioneye3 kernel: x86/split lock detection: #AC: crashing the kernel on kernel split_locks and warning on user-space split_locks
System info:
X86_64
motionEye 0.43.1b2
Motion 4.7.0
OS 6.1.0-28-amd64
@zagrim commented on GitHub (Jan 23, 2025):
That log is from when the system starts, what would be interesting is the log before that. If your system uses journald, try
journalctl -b-1 |tail -30to get last 30 lines before the most previous reboot.@macdroid53 commented on GitHub (Jan 23, 2025):
I think it ended up being a Debian Display manager problem.
I will provide this log info if it occurs again.
@macdroid53 commented on GitHub (Feb 4, 2025):
Ok it crashed after running for many days. Of course I was out of town when it happened and am just now getting to look into it. Here the journalctl output:
lasthang.txt
@zagrim commented on GitHub (Feb 9, 2025):
So the hang happened right after Feb 02 12:40:21 ? That log, unfortunately, doesn't seem to show anything that would hint about such. Could it be that the system is otherwise fine, but the video driver or display manager or Xorg/Wayland fails so that it appears to be frozen? Have you tried to SSH into the box when it appears hung? If that works, looking at X/Wayland logs might be helpful. In my Debian/Xorg box the file is
/var/log/Xorg.0.log.However, it looks a lot that your issue is not about Motion or MotionEye. The only way they should be able to cause a system to hang is Motion taking all the CPU time there is and causing the CPU to overheat, since neither should be able to hog memory on desktop-sized hardware in such amounts that it would cause serious issues. Then again, in such cases there possibly wouldn't be any evidence in system logs so it's hard to rule anything out without hooking the system up with some external monitoring to record CPU and mem usage.
@macdroid53 commented on GitHub (Feb 10, 2025):
Yes, ME is low on my list of suspects at this point.
But, I had said I'd get a log if it failed again.
As for ssh into the box, no, no ssh, no ping response, on response to keyboard or mouse...the box is completely unresponsive. Yet, the logs never show anything catastrophic before the hang, no memory usage increase.
There definitely wifi driver issues with the driver/chipset combination, but, I don't have wifi enabled. This is difficult to mess with since the chipset apparently does bot hardwired and wifi.
Since the machine runs fine otherwise, I may move ME to another PC and, hopefully be done with it.
@zagrim commented on GitHub (Feb 10, 2025):
Ok, sounds like kernel-level issue if the network interface also dies. Is the kernel you're running a Debian packaged one? If there are options to try another version of the kernel, that might help in case your issue is something that has been fixed in a newer kernel release (but what hasn't been backported by Debian) or that was introduced only rather recently (thus an older kernel might work better). But it's hard to diagnose this further.
If you always left the box running so that it is displaying the text console instead of your desktop manager GUI, you might be able to see something on the console after the hang occurs in case of kernel panic, but that would be more about getting confirmation to a hypothesis than getting any closer to resolving the issue.