youngvader Posted July 25, 2023 Share Posted July 25, 2023 Hello, Requesting assistance as my server during parity build/check become unresponsive. Only way to get access again is to restart the server by turning it off and on. It has always been my issue as I never get to complete the parity build. I have included the syslog file and diagnostics. I hope this is the correct files needed. Thank you and any help is greatly appreciated Jul 25 22:36:01 Tower rsyslogd: [origin software="rsyslogd" swVersion="8.2102.0" x-pid="22526" x-info="https://www.rsyslog.com"] start Jul 26 01:05:25 Tower apcupsd[3234]: Power failure. Jul 26 01:05:25 Tower apcupsd[3234]: Power is back. UPS running on mains. Jul 26 01:05:26 Tower apcupsd[3234]: Power failure. Jul 26 01:05:32 Tower apcupsd[3234]: Running on UPS batteries. Jul 26 01:05:41 Tower apcupsd[3234]: Mains returned. No longer on UPS batteries. Jul 26 01:05:41 Tower apcupsd[3234]: Power is back. UPS running on mains. Jul 26 01:06:53 Tower apcupsd[3234]: Power failure. Jul 26 01:06:58 Tower apcupsd[3234]: Power is back. UPS running on mains. Jul 26 03:40:16 Tower crond[1305]: exit status 1 from user root /usr/local/sbin/mover &> /dev/null Jul 26 05:53:09 Tower unassigned.devices: Mounting 'Auto Mount' Devices... Jul 26 05:53:09 Tower emhttpd: Starting services... Jul 26 05:53:09 Tower emhttpd: shcmd (201): /etc/rc.d/rc.samba restart Jul 26 05:53:09 Tower wsdd2[3317]: 'Terminated' signal received. Jul 26 05:53:09 Tower winbindd[3322]: [2023/07/26 05:53:09.852791, 0] ../../source3/winbindd/winbindd_dual.c:1957(winbindd_sig_term_handler) Jul 26 05:53:09 Tower winbindd[3320]: [2023/07/26 05:53:09.852801, 0] ../../source3/winbindd/winbindd_dual.c:1957(winbindd_sig_term_handler) Jul 26 05:53:09 Tower winbindd[3322]: Got sig[15] terminate (is_parent=0) Jul 26 05:53:09 Tower winbindd[3320]: Got sig[15] terminate (is_parent=1) Jul 26 05:53:09 Tower wsdd2[3317]: terminating. Jul 26 05:53:09 Tower winbindd[3415]: [2023/07/26 05:53:09.852941, 0] ../../source3/winbindd/winbindd_dual.c:1957(winbindd_sig_term_handler) Jul 26 05:53:09 Tower winbindd[3415]: Got sig[15] terminate (is_parent=0) Jul 26 05:53:10 Tower rsyslogd: [origin software="rsyslogd" swVersion="8.2102.0" x-pid="5110" x-info="https://www.rsyslog.com"] start Jul 26 05:53:11 Tower root: Starting Samba: /usr/sbin/smbd -D Jul 26 05:53:12 Tower smbd[5162]: [2023/07/26 05:53:12.021624, 0] ../../source3/smbd/server.c:1741(main) Jul 26 05:53:12 Tower smbd[5162]: smbd version 4.17.3 started. Jul 26 05:53:12 Tower smbd[5162]: Copyright Andrew Tridgell and the Samba Team 1992-2022 Jul 26 05:53:12 Tower root: /usr/sbin/wsdd2 -d Jul 26 05:53:12 Tower wsdd2[5193]: starting. Jul 26 05:53:12 Tower root: /usr/sbin/winbindd -D Jul 26 05:53:12 Tower winbindd[5194]: [2023/07/26 05:53:12.112793, 0] ../../source3/winbindd/winbindd.c:1440(main) Jul 26 05:53:12 Tower winbindd[5194]: winbindd version 4.17.3 started. Jul 26 05:53:12 Tower winbindd[5194]: Copyright Andrew Tridgell and the Samba Team 1992-2022 Jul 26 05:53:12 Tower winbindd[5196]: [2023/07/26 05:53:12.116374, 0] ../../source3/winbindd/winbindd_cache.c:3116(initialize_winbindd_cache) Jul 26 05:53:12 Tower winbindd[5196]: initialize_winbindd_cache: clearing cache and re-creating with version number 2 Jul 26 05:53:12 Tower emhttpd: shcmd (205): /etc/rc.d/rc.avahidaemon restart Jul 26 05:53:12 Tower root: Stopping Avahi mDNS/DNS-SD Daemon: stopped Jul 26 05:53:12 Tower avahi-dnsconfd[3346]: read(): EOF Jul 26 05:53:12 Tower root: Starting Avahi mDNS/DNS-SD Daemon: /usr/sbin/avahi-daemon -D Jul 26 05:53:12 Tower avahi-daemon[5226]: Found user 'avahi' (UID 61) and group 'avahi' (GID 214). Jul 26 05:53:12 Tower avahi-daemon[5226]: Successfully dropped root privileges. Jul 26 05:53:12 Tower avahi-daemon[5226]: avahi-daemon 0.8 starting up. Jul 26 05:53:12 Tower avahi-daemon[5226]: Successfully called chroot(). Jul 26 05:53:12 Tower avahi-daemon[5226]: Successfully dropped remaining capabilities. Jul 26 05:53:12 Tower avahi-daemon[5226]: Loading service file /services/sftp-ssh.service. Jul 26 05:53:12 Tower avahi-daemon[5226]: Loading service file /services/smb.service. Jul 26 05:53:12 Tower avahi-daemon[5226]: Loading service file /services/ssh.service. Jul 26 05:53:12 Tower avahi-daemon[5226]: Joining mDNS multicast group on interface br0.IPv4 with address 192.168.10.82. Jul 26 05:53:12 Tower avahi-daemon[5226]: New relevant interface br0.IPv4 for mDNS. Jul 26 05:53:12 Tower avahi-daemon[5226]: Joining mDNS multicast group on interface lo.IPv6 with address ::1. Jul 26 05:53:12 Tower avahi-daemon[5226]: New relevant interface lo.IPv6 for mDNS. Jul 26 05:53:12 Tower avahi-daemon[5226]: Joining mDNS multicast group on interface lo.IPv4 with address 127.0.0.1. Jul 26 05:53:12 Tower avahi-daemon[5226]: New relevant interface lo.IPv4 for mDNS. Jul 26 05:53:12 Tower avahi-daemon[5226]: Network interface enumeration completed. Jul 26 05:53:12 Tower avahi-daemon[5226]: Registering new address record for 192.168.10.82 on br0.IPv4. Jul 26 05:53:12 Tower avahi-daemon[5226]: Registering new address record for ::1 on lo.*. Jul 26 05:53:12 Tower avahi-daemon[5226]: Registering new address record for 127.0.0.1 on lo.IPv4. Jul 26 05:53:12 Tower emhttpd: shcmd (206): /etc/rc.d/rc.avahidnsconfd restart Jul 26 05:53:12 Tower root: Stopping Avahi mDNS/DNS-SD DNS Server Configuration Daemon: stopped Jul 26 05:53:12 Tower root: Starting Avahi mDNS/DNS-SD DNS Server Configuration Daemon: /usr/sbin/avahi-dnsconfd -D Jul 26 05:53:12 Tower avahi-dnsconfd[5237]: Successfully connected to Avahi daemon. Jul 26 05:53:12 Tower emhttpd: shcmd (217): /usr/local/sbin/mount_image '/mnt/user/system/docker/docker.img' /var/lib/docker 20 Jul 26 05:53:12 Tower kernel: loop2: detected capacity change from 0 to 41943040 Jul 26 05:53:12 Tower kernel: BTRFS: device fsid 483a16b7-23a7-4e0e-8790-43e553ba7808 devid 1 transid 77577 /dev/loop2 scanned by mount (5281) Jul 26 05:53:12 Tower kernel: BTRFS info (device loop2): using free space tree Jul 26 05:53:12 Tower kernel: BTRFS info (device loop2): has skinny extents Jul 26 05:53:12 Tower kernel: BTRFS info (device loop2): enabling ssd optimizations Jul 26 05:53:12 Tower kernel: BTRFS info (device loop2): start tree-log replay Jul 26 05:53:12 Tower kernel: BTRFS info (device loop2): checking UUID tree Jul 26 05:53:12 Tower root: Resize device id 1 (/dev/loop2) from 20.00GiB to max Jul 26 05:53:12 Tower emhttpd: shcmd (219): /etc/rc.d/rc.docker start Jul 26 05:53:12 Tower root: starting dockerd ... Jul 26 05:53:13 Tower kernel: Bridge firewalling registered Jul 26 05:53:13 Tower avahi-daemon[5226]: Server startup complete. Host name is Tower.local. Local service cookie is 1047024418. Jul 26 05:53:13 Tower kernel: Initializing XFRM netlink socket Jul 26 05:53:13 Tower avahi-daemon[5226]: Joining mDNS multicast group on interface br-5068543868cb.IPv4 with address 172.31.200.1. Jul 26 05:53:13 Tower avahi-daemon[5226]: New relevant interface br-5068543868cb.IPv4 for mDNS. Jul 26 05:53:13 Tower avahi-daemon[5226]: Registering new address record for 172.31.200.1 on br-5068543868cb.IPv4. Jul 26 05:53:13 Tower avahi-daemon[5226]: Joining mDNS multicast group on interface docker0.IPv4 with address 172.17.0.1. Jul 26 05:53:13 Tower avahi-daemon[5226]: New relevant interface docker0.IPv4 for mDNS. Jul 26 05:53:13 Tower avahi-daemon[5226]: Registering new address record for 172.17.0.1 on docker0.IPv4. Jul 26 05:53:14 Tower avahi-daemon[5226]: Service "Tower" (/services/sftp-ssh.service) successfully established. Jul 26 05:53:14 Tower avahi-daemon[5226]: Service "Tower" (/services/smb.service) successfully established. Jul 26 05:53:14 Tower avahi-daemon[5226]: Service "Tower" (/services/ssh.service) successfully established. Jul 26 05:53:14 Tower kernel: docker0: port 1(vetha093cdc) entered blocking state Jul 26 05:53:14 Tower kernel: docker0: port 1(vetha093cdc) entered disabled state Jul 26 05:53:14 Tower kernel: device vetha093cdc entered promiscuous mode Jul 26 05:53:14 Tower kernel: docker0: port 1(vetha093cdc) entered blocking state Jul 26 05:53:14 Tower kernel: docker0: port 1(vetha093cdc) entered forwarding state Jul 26 05:53:14 Tower kernel: docker0: port 1(vetha093cdc) entered disabled state Jul 26 05:53:14 Tower emhttpd: shcmd (233): /usr/local/sbin/mount_image '/mnt/user/system/libvirt/libvirt.img' /etc/libvirt 1 Jul 26 05:53:14 Tower kernel: loop3: detected capacity change from 0 to 2097152 Jul 26 05:53:14 Tower kernel: BTRFS: device fsid 289e35a5-b643-42dd-9eb7-689264587140 devid 1 transid 260 /dev/loop3 scanned by mount (6036) Jul 26 05:53:14 Tower kernel: BTRFS info (device loop3): using free space tree Jul 26 05:53:14 Tower kernel: BTRFS info (device loop3): has skinny extents Jul 26 05:53:14 Tower kernel: BTRFS info (device loop3): enabling ssd optimizations Jul 26 05:53:14 Tower root: Resize device id 1 (/dev/loop3) from 1.00GiB to max Jul 26 05:53:14 Tower emhttpd: shcmd (235): /etc/rc.d/rc.libvirt start Jul 26 05:53:14 Tower root: Starting virtlockd... Jul 26 05:53:14 Tower root: Starting virtlogd... Jul 26 05:53:14 Tower root: Starting libvirtd... Jul 26 05:53:14 Tower kernel: tun: Universal TUN/TAP device driver, 1.6 Jul 26 05:53:14 Tower kernel: mdcmd (36): check Jul 26 05:53:14 Tower kernel: md: recovery thread: recon P ... Jul 26 05:53:14 Tower kernel: eth0: renamed from veth431f196 Jul 26 05:53:14 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vetha093cdc: link becomes ready Jul 26 05:53:14 Tower kernel: docker0: port 1(vetha093cdc) entered blocking state Jul 26 05:53:14 Tower kernel: docker0: port 1(vetha093cdc) entered forwarding state Jul 26 05:53:14 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): docker0: link becomes ready Jul 26 05:53:14 Tower rc.docker: duckdns: started succesfully! Jul 26 05:53:15 Tower avahi-daemon[5226]: Joining mDNS multicast group on interface virbr0.IPv4 with address 192.168.122.1. Jul 26 05:53:15 Tower avahi-daemon[5226]: New relevant interface virbr0.IPv4 for mDNS. Jul 26 05:53:15 Tower avahi-daemon[5226]: Registering new address record for 192.168.122.1 on virbr0.IPv4. Jul 26 05:53:15 Tower dnsmasq[6288]: started, version 2.87 cachesize 150 Jul 26 05:53:15 Tower dnsmasq[6288]: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset no-nftset auth cryptohash DNSSEC loop-detect inotify dumpfile Jul 26 05:53:15 Tower dnsmasq-dhcp[6288]: DHCP, IP range 192.168.122.2 -- 192.168.122.254, lease time 1h Jul 26 05:53:15 Tower dnsmasq-dhcp[6288]: DHCP, sockets bound exclusively to interface virbr0 Jul 26 05:53:15 Tower dnsmasq[6288]: reading /etc/resolv.conf Jul 26 05:53:15 Tower dnsmasq[6288]: using nameserver 9.9.9.9#53 Jul 26 05:53:15 Tower dnsmasq[6288]: using nameserver 1.1.1.1#53 Jul 26 05:53:15 Tower dnsmasq[6288]: read /etc/hosts - 2 addresses Jul 26 05:53:15 Tower dnsmasq[6288]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses Jul 26 05:53:15 Tower dnsmasq-dhcp[6288]: read /var/lib/libvirt/dnsmasq/default.hostsfile Jul 26 05:53:15 Tower kernel: L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html for details. Jul 26 05:53:15 Tower rc.docker: Plex-Media-Server: started succesfully! Jul 26 05:53:16 Tower avahi-daemon[5226]: Joining mDNS multicast group on interface docker0.IPv6 with address fe80::42:1ff:fe58:fd64. Jul 26 05:53:16 Tower avahi-daemon[5226]: New relevant interface docker0.IPv6 for mDNS. Jul 26 05:53:16 Tower avahi-daemon[5226]: Registering new address record for fe80::42:1ff:fe58:fd64 on docker0.*. Jul 26 05:53:16 Tower avahi-daemon[5226]: Joining mDNS multicast group on interface vetha093cdc.IPv6 with address fe80::e863:1fff:fef6:5c48. Jul 26 05:53:16 Tower avahi-daemon[5226]: New relevant interface vetha093cdc.IPv6 for mDNS. Jul 26 05:53:16 Tower avahi-daemon[5226]: Registering new address record for fe80::e863:1fff:fef6:5c48 on vetha093cdc.*. Jul 26 05:53:16 Tower unassigned.devices: Mounting 'Auto Mount' Remote Shares... Jul 26 05:53:16 Tower unassigned.devices: Using Gateway '192.168.10.1' to Ping Remote Shares. Jul 26 05:53:16 Tower sudo: root : PWD=/ ; USER=root ; COMMAND=/bin/bash -c /usr/local/emhttp/plugins/unbalance/unbalance -port 6237 Jul 26 05:53:16 Tower sudo: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=0) Jul 26 05:53:16 Tower unassigned.devices: Waiting 5 secs before mounting Remote Shares... Jul 26 05:53:22 Tower unassigned.devices: Remote Share '//192.168.10.61/Downloads' is not set to auto mount. tower-diagnostics-20230726-0602.zip Quote Link to comment
itimpi Posted July 25, 2023 Share Posted July 25, 2023 Are you sure you do not have any power related issues (either PSU or cabling to it). The parity build/check are times when it is likely to be under maximum stress. Quote Link to comment
youngvader Posted July 26, 2023 Author Share Posted July 26, 2023 Hello, thank you for your response. I cannot 100% say that there is no PSU issue but everytime when server is unresponsive the server is still powered ON. Is there anything on the syslog and diagnostics that suggests it might have been a PSU issue? anything else I can check? Quote Link to comment
youngvader Posted July 26, 2023 Author Share Posted July 26, 2023 Additional information. The parity build/check is always more than 50% complete before it will suddenly become unresponsive Quote Link to comment
David Grenon Posted July 26, 2023 Share Posted July 26, 2023 It seems that I have similar issue as you. And nothing in my logs seems to point something. Never had this issue before Version: 6.12.3. Parity check is running and during the day my dockers seems to have stopped working. Restarting the service hanged and by refreshing the page I now see the service is stopped. Now I can't even go back to docker section to restart the service. My parity check is still running and its at around 60% now. Quote Link to comment
youngvader Posted July 26, 2023 Author Share Posted July 26, 2023 1 hour ago, David Grenon said: It seems that I have similar issue as you. And nothing in my logs seems to point something. Never had this issue before Version: 6.12.3. Parity check is running and during the day my dockers seems to have stopped working. Restarting the service hanged and by refreshing the page I now see the service is stopped. Now I can't even go back to docker section to restart the service. My parity check is still running and its at around 60% now. I hope someone can help us. It’s frustrating that I still don’t have parity because of this issue. Quote Link to comment
itimpi Posted July 26, 2023 Share Posted July 26, 2023 The syslog provided earlier is just the RAM copy that is included in the diagnostics zip file and just shows what happened since the last boot. I suggest that you enable the syslog server to try and get a syslog that can survive a reboot. Quote Link to comment
youngvader Posted July 26, 2023 Author Share Posted July 26, 2023 46 minutes ago, itimpi said: The syslog provided earlier is just the RAM copy that is included in the diagnostics zip file and just shows what happened since the last boot. I suggest that you enable the syslog server to try and get a syslog that can survive a reboot. I have included the syslog server and copied it together with my original post. Unless i’m mistaken and its incomplete. Quote Link to comment
youngvader Posted July 26, 2023 Author Share Posted July 26, 2023 (edited) 52 minutes ago, itimpi said: The syslog provided earlier is just the RAM copy that is included in the diagnostics zip file and just shows what happened since the last boot. I suggest that you enable the syslog server to try and get a syslog that can survive a reboot. Server become unresponsive again just now during parity sync. Attaching syslog server syslog-192.168.10.82-3.log Edited July 26, 2023 by youngvader Quote Link to comment
itimpi Posted July 26, 2023 Share Posted July 26, 2023 1 hour ago, youngvader said: Server become unresponsive again just now during parity sync. Attaching syslog server syslog-192.168.10.82-3.log 23.52 kB · 1 download Unfortunately I cannot see anything in that log that gives a hint as to what the problem might be. Quote Link to comment
youngvader Posted July 26, 2023 Author Share Posted July 26, 2023 12 minutes ago, itimpi said: Unfortunately I cannot see anything in that log that gives a hint as to what the problem might be. Thank you for your help. I hope there are others out there that have other possible solutions. Quote Link to comment
JorgeB Posted July 31, 2023 Share Posted July 31, 2023 Is this a new problem or you've never have been able to complete a check? In any case this looks more like a hardware issue. Quote Link to comment
David Grenon Posted August 2, 2023 Share Posted August 2, 2023 On 7/26/2023 at 1:07 AM, youngvader said: I hope someone can help us. It’s frustrating that I still don’t have parity because of this issue. Update: Now I need to reboot my server on a daily basis (pull the cord) because I can't connect through ssh or web server.... If they dont fix it soon ill revert to earlier version...ths is ridiculous. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.