Closed chegeiser closed 5 years ago
What device are you using? Could you run these commands:
journalctl
dmesg
Device is an Odroid-N2
Output of the two commands attached.
It looks like there's a large number of login attempts from IP addresses in China (that's not me). Could this be enough to crash the system? Or is there something else going on?
I also notice that the time stamp in the journalctl jumps from Jan 01 to Oct 10 (yesterday). Is this normal? Does the system startup and log Jan 01 and once a particular service is started then the clock/date adjusts? This is at row 1235 in the journactl output file.
Looks like systemd udev has some issies:
242.699946] INFO: task systemd-udevd:2015 blocked for more than 120 seconds.
[ 242.701527] Not tainted 4.9.162-22 #1
[ 242.706281] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 242.714189] systemd-udevd D 0 2015 2007 0x00400001
[ 242.719463] Call trace:
[ 242.722383] [<ffffff80090867ec>] __switch_to+0x9c/0xc0
[ 242.727465] [<ffffff8009bfa6a4>] __schedule+0x284/0x7e0
[ 242.732781] [<ffffff8009bfac40>] schedule+0x40/0xa8
[ 242.737774] [<ffffff8009bfb0d0>] schedule_preempt_disabled+0x28/0x40
[ 242.744267] [<ffffff8009bfcc50>] __mutex_lock_slowpath+0x108/0x1e8
[ 242.750593] [<ffffff8009bfcd90>] mutex_lock+0x60/0x78
[ 242.755790] [<ffffff80095b233c>] lo_release+0x2c/0xd8
[ 242.760986] [<ffffff800927fb2c>] __blkdev_put+0x234/0x270
[ 242.766530] [<ffffff800927ffbc>] blkdev_put+0x54/0x148
[ 242.771818] [<ffffff80092800dc>] blkdev_close+0x2c/0x40
[ 242.777190] [<ffffff800923c570>] __fput+0xa8/0x1e8
[ 242.782129] [<ffffff800923c728>] ____fput+0x20/0x30
[ 242.787158] [<ffffff80090cb260>] task_work_run+0xd0/0x100
[ 242.792704] [<ffffff800908ae14>] do_notify_resume+0xb4/0xc0
[ 242.798424] [<ffffff8009083878>] work_pending+0x8/0x10
Yes, it prevents apps from mounting:
Jan 01 00:01:41 odroid-n2 systemd[1]: snap-platform-1905051083.mount mounting timed out. Stopping.
Jan 01 00:01:42 odroid-n2 systemd[1]: snap-syncthing-190629147.mount mounting timed out. Stopping.
Jan 01 00:01:42 odroid-n2 systemd[1]: snap-syncthing-190625132.mount mounting timed out. Stopping.
Jan 01 00:01:42 odroid-n2 systemd[1]: snap-nextcloud-1909118.mount mounting timed out. Stopping.
Jan 01 00:01:42 odroid-n2 systemd[1]: snap-notes-19040763.mount mounting timed out. Stopping.
Jan 01 00:01:42 odroid-n2 systemd[1]: snap-nextcloud-190712444.mount mounting timed out. Stopping.
Jan 01 00:01:42 odroid-n2 systemd[1]: snap-platform-19092245.mount mounting timed out. Stopping.
Jan 01 00:01:42 odroid-n2 systemd[1]: snap-platform-1907121131.mount mounting timed out. Stopping.
Jan 01 00:01:42 odroid-n2 systemd[1]: snap-nextcloud-190211412.mount mounting timed out. Stopping.
Jan 01 00:03:12 odroid-n2 systemd[1]: snap-platform-1905051083.mount mounting timed out. Killing.
Jan 01 00:03:12 odroid-n2 systemd[1]: snap-syncthing-190629147.mount mounting timed out. Killing.
Jan 01 00:03:12 odroid-n2 systemd[1]: snap-syncthing-190625132.mount mounting timed out. Killing.
Jan 01 00:03:12 odroid-n2 systemd[1]: snap-nextcloud-1909118.mount mounting timed out. Killing.
Jan 01 00:03:12 odroid-n2 systemd[1]: snap-notes-19040763.mount mounting timed out. Killing.
Jan 01 00:03:12 odroid-n2 systemd[1]: snap-nextcloud-190712444.mount mounting timed out. Killing.
Jan 01 00:03:12 odroid-n2 systemd[1]: snap-platform-19092245.mount mounting timed out. Killing.
Jan 01 00:03:12 odroid-n2 systemd[1]: snap-platform-1907121131.mount mounting timed out. Killing.
Jan 01 00:03:12 odroid-n2 systemd[1]: snap-nextcloud-190211412.mount mounting timed out. Killing.
Jan 01 00:03:12 odroid-n2 systemd-udevd[2007]: worker [2015] /devices/virtual/block/loop6 timeout; kill it
Jan 01 00:03:12 odroid-n2 systemd-udevd[2007]: seq 3017 '/devices/virtual/block/loop6' killed
Jan 01 00:03:12 odroid-n2 systemd-udevd[2007]: worker [2018] /devices/virtual/block/loop7 timeout; kill it
Jan 01 00:03:12 odroid-n2 systemd-udevd[2007]: seq 3018 '/devices/virtual/block/loop7' killed
Jan 01 00:03:12 odroid-n2 systemd-udevd[2007]: worker [2022] /devices/virtual/block/loop4 timeout; kill it
Jan 01 00:03:12 odroid-n2 systemd-udevd[2007]: seq 3015 '/devices/virtual/block/loop4' killed
Jan 01 00:03:12 odroid-n2 systemd-udevd[2007]: worker [2023] /devices/virtual/block/loop0 timeout; kill it
Jan 01 00:03:12 odroid-n2 systemd-udevd[2007]: seq 3011 '/devices/virtual/block/loop0' killed
Jan 01 00:03:12 odroid-n2 systemd-udevd[2007]: worker [2028] /devices/virtual/block/loop1 timeout; kill it
Jan 01 00:03:12 odroid-n2 systemd-udevd[2007]: seq 3012 '/devices/virtual/block/loop1' killed
Jan 01 00:03:12 odroid-n2 systemd-udevd[2007]: worker [2029] /devices/virtual/block/loop5 timeout; kill it
Jan 01 00:03:12 odroid-n2 systemd-udevd[2007]: seq 3016 '/devices/virtual/block/loop5' killed
Jan 01 00:03:12 odroid-n2 systemd-udevd[2007]: worker [2030] /devices/virtual/block/loop2 timeout; kill it
Jan 01 00:03:12 odroid-n2 systemd-udevd[2007]: seq 3013 '/devices/virtual/block/loop2' killed
Jan 01 00:03:12 odroid-n2 systemd-udevd[2007]: worker [2031] /devices/virtual/block/loop3 timeout; kill it
Jan 01 00:03:12 odroid-n2 systemd-udevd[2007]: seq 3014 '/devices/virtual/block/loop3' killed
Jan 01 00:04:02 odroid-n2 kernel: INFO: task systemd-udevd:2015 blocked for more than 120 seconds.
Jan 01 00:04:02 odroid-n2 kernel: Not tainted 4.9.162-22 #1
Jan 01 00:04:02 odroid-n2 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 01 00:04:02 odroid-n2 kernel: systemd-udevd D 0 2015 2007 0x00400001
Did you power off/on the device in the end?
Looks like not all the devices support software reboot.
Sorry you actually powered it off. Strange, not sure how can it stuck like this unless sd card (or other type of memory it uses) corrupted.
I am actually OK to remove shutdown/reboot buttons as I do not really know how to handle it properly on vatious devices and this situation you are showing is really bad to be in.
So the only way to shutdown would be ssh, correct?
Any ideas of fixes? Or is this really going to require a fresh image?
I went ahead and re-imaged, and then restored from the backup created through Syncloud Settings. Everything is back as it was. Going forward I'll be sure to use SSH to shutdown and/or reboot instead of the built-in Shutdown/Reboot.
Syncloud runs these commands on the device:
Reboot:
shutdown -r now
Shutdown:
shutdown now
https://github.com/syncloud/platform/blob/master/src/syncloud_platform/control/power.py
I do not think running them with ssh makes any difference.
shutdown -r now
works from ssh terminal. Apps start up properly on reboot. Is this going to be in the next update whenever it comes out?
Thank you!
This is what we always had. Can you try to do the same from the UI?
Tried via the UI and it worked. Don’t know what caused the original problem. May have been power loss. Will get a UPS set up to avoid issues there.
I ran a restart from the platform restart option (Shutdown>Restart). When it restarted I couldn't get in to the system, not even into the main syncloud admin interface - there's no webserver error so it seems the webserver is down. I went in through ssh and shutdown, pulled the power for a few minutes, then rebooted. No luck getting in.
I've run
systemctl status snap.platform.*
and got this:I tried
systemctl status
and gut thisAnd
systemctl
gives thisAny ideas how to get this running? This happened before, but I did at least have access to the admin page and was then able to restore the apps. Seems the reboot causes some issue.
Thanks, Che