Neo_x Posted July 5, 2015 Share Posted July 5, 2015 Hi guys This is quite an odd one, and i hope someone can shed some light. I followed the Limetech upgrade package yesterday as per : https://lime-technology.com/forum/index.php?topic=41061.0 Before starting that, i went into my go file, and disabled all additional packages(mostly just a fan script and unmenu, and rebooted the server. upgrade went without any hitches (and i noticed that the upgrade actually moves all old files into a backup folder, which basically gives me a blank copy to start with.) having prepared a drive before the time, i then started the conversion to xfs (eg formatting a blank drive to XFS, and then copying a full disk to the blank disk - this is/was still going( ETA about 30 hours for 4TB) (i was using screen and mc to accomplish this) my issue is, after about 14 hours, i lost connectivity to the HTTP interface as well as SMB (eg i couldn't start a movie via Kodi) telnet access still worked, after which i tried to reboot the server (sudo reboot) as well as powerdown - both failed - after which i gave it a hard reset (this came up with a parity check which i opted to cancel). I then resumed the XFS migration -all is wel with http access again. this morning, about 8 hours later, the issue repeated - thus i would like to troubleshoot possible causes and get assistance on how to correct this? ( note reverting to V5 is a bit of a mission due to the one XFS drive) ps -a capture http://pastebin.com/4D7Y98ji syslog capture http://pastebin.com/1skRBstL Diagnostics capture http://filebin.ca/27ZlpkrT5H3W i have played around with some of the dynamix plugins, but opted to remove them afterwards to insure some stability during the xfs migration. only package that should be active is nerdpack (to allow me to use screen) any recommendations please? regards Neo_x PS even though the emhttp and SMB issues is active, mc is still copying happily between the [souce] and [dest]/t *edit* added the diagnostics capture. Currently doing a new v6 install from scratch (only restoring disck / network / ident and share config files. will report back if issue occurs again.. Link to comment
dgaschk Posted July 5, 2015 Share Posted July 5, 2015 If it happens again start in SAFE-mode. Link to comment
Neo_x Posted July 6, 2015 Author Share Posted July 6, 2015 If it happens again start in SAFE-mode. not sure how to start safe mode? is this possible without having to connect a screen/keyboard? it happened twice again now (eg stock unraid 6.0.1 with only nerdpack added). stayed up for about 12 hours yesterday, as it was streaming movies to the family. this morning it is down again, and even worse - the NFS copy running under MC has crashed/stuck as well thus: GUI down SMB down telnet - Up list user share under telnet - fail ps -ef http://pastebin.com/M2Gvw1wm Top http://pastebin.com/Kd16pcDF lsof -Pni http://pastebin.com/Xq6bfVPf diagnostics capture : http://filebin.ca/27ep8OtR0vNg i managed to perform a diagnost'>http://filebin.ca/27epLpGa0mPY i managed to perform a diagnostics capture, although during capture it reports : root@Storage:~# diagnostics cp: cannot stat ‘/boot/config/*.conf’: No such file or directory didnt have any of this under v5 - and i am running as close to a stock system as possible - no dockers/packages etc ( although nerdpack seems a bit bloated) :'( i will attempt starting safe mode tonight - as connecting screens etc is a bit challenging. *edit - seems possible with editing syslinux * will this syslinux cause safemode? default /syslinux/menu.c32 menu title Lime Technology prompt 0 timeout 50 label unRAID OS kernel /bzimage append initrd=/bzroot label unRAID OS Safe Mode (no plugins) menu default kernel /bzimage append initrd=/bzroot unraidsafemode label Memtest86+ kernel /memtest i have updated my go file as per your signature, although there was no additional go file lines. *edit2* ok safemode seems to be going well as per above. screen etc is not working, and only packages installed shows only dynamix will leave this running for a day or two Link to comment
bonienl Posted July 6, 2015 Share Posted July 6, 2015 This line emhttp 6579 root 5u IPv4 466819 0t0 TCP 127.0.0.1:80->127.0.0.1:60171 (CLOSE_WAIT) Indicates that emhttp is waiting for another process to finish. Not sure what is going on, but you have a suspicious high number of smbd processes. Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.