November 30, 201510 yr Nov 30 14:08:58 Pithos powerdown[29990]: Powerdown initiated Nov 30 14:08:58 Pithos powerdown[29996]: Powerdown V2.18 Nov 30 14:08:58 Pithos rc.unRAID[30000][30004]: Processing /etc/rc.d/rc.unRAID.d/ kill services scripts. Nov 30 14:08:58 Pithos rc.unRAID[30008][30012]: Processing /etc/rc.d/rc.unRAID.d/ kill scripts. Nov 30 14:08:58 Pithos rc.unRAID[30008][30016]: Running: "/etc/rc.d/rc.unRAID.d/K00.sh" Nov 30 14:08:58 Pithos rc.unRAID[30008][30019]: Shutdown NOW! Nov 30 14:08:58 Pithos rc.unRAID[30008][30019]: #015 Nov 30 14:08:58 Pithos rc.unRAID[30008][30019]: System shutdown time has arrived#007#007#015 Nov 30 14:08:58 Pithos rc.unRAID[30008][30019]: Connection to 192.168.00.83 closed by remote host.#015 Nov 30 14:09:01 Pithos kernel: br0: port 3(vnet1) entered disabled state Nov 30 14:09:01 Pithos avahi-daemon[26230]: Withdrawing workstation service for vnet1. Nov 30 14:09:01 Pithos kernel: device vnet1 left promiscuous mode Nov 30 14:09:01 Pithos kernel: br0: port 3(vnet1) entered disabled state Nov 30 14:09:01 Pithos kernel: irq 16: nobody cared (try booting with the "irqpoll" option) Nov 30 14:09:01 Pithos kernel: CPU: 4 PID: 0 Comm: swapper/4 Not tainted 4.1.13-unRAID #1 Nov 30 14:09:01 Pithos kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./H77 Pro4-M, BIOS P2.00 08/06/2013 Nov 30 14:09:01 Pithos kernel: 0000000000000000 ffff88044f303e18 ffffffff815f12b0 0000000000000001 Nov 30 14:09:01 Pithos kernel: ffff88043ca56a00 ffff88044f303e48 ffffffff8107b05f 00000000ffff5cb3 Nov 30 14:09:01 Pithos kernel: ffff88043ca56a00 0000000000000000 0000000000000010 ffff88044f303e88 Nov 30 14:09:01 Pithos kernel: Call Trace: Nov 30 14:09:01 Pithos kernel: <IRQ> [<ffffffff815f12b0>] dump_stack+0x4c/0x6e Nov 30 14:09:01 Pithos kernel: [<ffffffff8107b05f>] __report_bad_irq+0x2b/0xbe Nov 30 14:09:01 Pithos kernel: [<ffffffff8107b46a>] note_interrupt+0x19d/0x227 Nov 30 14:09:01 Pithos kernel: [<ffffffff81079460>] handle_irq_event_percpu+0xe0/0xf2 Nov 30 14:09:01 Pithos kernel: [<ffffffff810794ae>] handle_irq_event+0x3c/0x5e Nov 30 14:09:01 Pithos kernel: [<ffffffff8107bcc7>] handle_fasteoi_irq+0x7a/0xdb Nov 30 14:09:01 Pithos kernel: [<ffffffff8100cf66>] handle_irq+0x1a/0x24 Nov 30 14:09:01 Pithos kernel: [<ffffffff8108f6ee>] ? __tick_nohz_idle_enter+0x27e/0x308 Nov 30 14:09:01 Pithos kernel: [<ffffffff8100c9f8>] do_IRQ+0x49/0xcd Nov 30 14:09:01 Pithos kernel: [<ffffffff815f74ae>] common_interrupt+0x6e/0x6e Nov 30 14:09:01 Pithos kernel: <EOI> [<ffffffff814dd3ad>] ? cpuidle_enter_state+0xb9/0x114 Nov 30 14:09:01 Pithos kernel: [<ffffffff814dd343>] ? cpuidle_enter_state+0x4f/0x114 Nov 30 14:09:01 Pithos kernel: [<ffffffff814dd42a>] cpuidle_enter+0x12/0x14 Nov 30 14:09:01 Pithos kernel: [<ffffffff810728ac>] cpu_startup_entry+0x1e2/0x2b2 Nov 30 14:09:01 Pithos kernel: [<ffffffff810324d4>] start_secondary+0x10e/0x12c Nov 30 14:09:01 Pithos kernel: handlers: Nov 30 14:09:01 Pithos kernel: [<ffffffff81486040>] vfio_intx_handler Nov 30 14:09:01 Pithos kernel: Disabling IRQ #16 Nov 30 14:09:03 Pithos K00.sh: Remote Shutdown OSX Machine Nov 30 14:09:03 Pithos powerdown[30143]: Initiating Shutdown with '-r' Nov 30 14:09:03 Pithos shutdown[30144]: shutting down for system reboot Nov 30 14:09:04 Pithos init: Switching to runlevel: 6 Nov 30 14:09:06 Pithos rc.unRAID[30194][30198]: Powerdown V2.18 Nov 30 14:09:06 Pithos rc.unRAID[30194][30202]: Stopping Plugins. Nov 30 14:09:06 Pithos rc.unRAID[30194][30203]: Running: "/usr/local/emhttp/plugins/dynamix.cache.dirs/event/stopping_svcs" Nov 30 14:09:06 Pithos cache_dirs: killing cache_dirs process 25964 Nov 30 14:09:06 Pithos rc.unRAID[30194][30222]: Running: "/usr/local/emhttp/plugins/dynamix.docker.manager/event/stopping_svcs" Nov 30 14:09:06 Pithos rc.unRAID[30194][30225]: Stopping Docker... Nov 30 14:09:06 Pithos logger: stopping docker ... Nov 30 14:09:06 Pithos logger: df36c7c88860 Nov 30 14:09:16 Pithos kernel: veth3fb2bf0: renamed from eth0 Nov 30 14:09:16 Pithos kernel: docker0: port 4(veth54a5240) entered disabled state Nov 30 14:09:16 Pithos kernel: docker0: port 4(veth54a5240) entered disabled state Nov 30 14:09:16 Pithos avahi-daemon[26230]: Withdrawing workstation service for veth3fb2bf0. Nov 30 14:09:16 Pithos avahi-daemon[26230]: Withdrawing workstation service for veth54a5240. Nov 30 14:09:16 Pithos kernel: device veth54a5240 left promiscuous mode Nov 30 14:09:16 Pithos kernel: docker0: port 4(veth54a5240) entered disabled state Nov 30 14:09:16 Pithos logger: 4e47417b44a6 Nov 30 14:09:17 Pithos emhttp: cmd: /usr/local/emhttp/plugins/dynamix/scripts/tail_log syslog Nov 30 14:09:26 Pithos kernel: vethd81503c: renamed from eth0 Nov 30 14:09:26 Pithos kernel: docker0: port 3(veth902a408) entered disabled state Nov 30 14:09:26 Pithos kernel: docker0: port 3(veth902a408) entered disabled state Nov 30 14:09:26 Pithos avahi-daemon[26230]: Withdrawing workstation service for vethd81503c. Nov 30 14:09:26 Pithos avahi-daemon[26230]: Withdrawing workstation service for veth902a408. Nov 30 14:09:26 Pithos kernel: device veth902a408 left promiscuous mode Nov 30 14:09:26 Pithos kernel: docker0: port 3(veth902a408) entered disabled state Nov 30 14:09:26 Pithos logger: 92fe79d45127 Nov 30 14:09:26 Pithos kernel: veth94f5539: renamed from eth0 Nov 30 14:09:26 Pithos kernel: docker0: port 2(vethb3f837a) entered disabled state Nov 30 14:09:26 Pithos kernel: docker0: port 2(vethb3f837a) entered disabled state Nov 30 14:09:26 Pithos avahi-daemon[26230]: Withdrawing workstation service for veth94f5539. Nov 30 14:09:26 Pithos avahi-daemon[26230]: Withdrawing workstation service for vethb3f837a. Nov 30 14:09:26 Pithos kernel: device vethb3f837a left promiscuous mode Nov 30 14:09:26 Pithos kernel: docker0: port 2(vethb3f837a) entered disabled state Nov 30 14:09:26 Pithos logger: 7354a5ccd338 Nov 30 14:09:26 Pithos kernel: veth61de4b4: renamed from eth0 Nov 30 14:09:26 Pithos kernel: docker0: port 1(veth6ea4e5d) entered disabled state Nov 30 14:09:26 Pithos kernel: docker0: port 1(veth6ea4e5d) entered disabled state Nov 30 14:09:26 Pithos avahi-daemon[26230]: Withdrawing workstation service for veth61de4b4. Nov 30 14:09:26 Pithos avahi-daemon[26230]: Withdrawing workstation service for veth6ea4e5d. Nov 30 14:09:26 Pithos kernel: device veth6ea4e5d left promiscuous mode Nov 30 14:09:26 Pithos kernel: docker0: port 1(veth6ea4e5d) entered disabled state Nov 30 14:09:26 Pithos logger: aac9293e44a5 Nov 30 14:09:27 Pithos logger: unmounting docker loopback Nov 30 14:09:28 Pithos rc.unRAID[30194][31218]: Running: "/usr/local/emhttp/plugins/dynamix.vm.manager/event/stopping_svcs" Nov 30 14:09:28 Pithos rc.unRAID[30194][31221]: Stopping libvirt... Nov 30 14:09:28 Pithos ntpd[1567]: Deleting interface #2 docker0, 172.17.42.1#123, interface stats: received=0, sent=0, dropped=0, active_time=239 secs Nov 30 14:09:33 Pithos logger: Domain fbf3f0fb-ec17-a43e-37f0-0a7d9f67f7a6 is being shutdown Nov 30 14:09:33 Pithos logger: Nov 30 14:09:34 Pithos kernel: br0: port 2(vnet0) entered disabled state Nov 30 14:09:34 Pithos kernel: device vnet0 left promiscuous mode Nov 30 14:09:34 Pithos kernel: br0: port 2(vnet0) entered disabled state Nov 30 14:09:34 Pithos avahi-daemon[26230]: Withdrawing workstation service for vnet0. Nov 30 14:09:38 Pithos logger: Domain 06c9e45e-2bf5-9cf4-4ac1-6cce45fbcaaa is being shutdown Nov 30 14:09:38 Pithos logger: Nov 30 14:10:10 Pithos kernel: irq 16: nobody cared (try booting with the "irqpoll" option) Nov 30 14:10:10 Pithos kernel: CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.1.13-unRAID #1 Nov 30 14:10:10 Pithos kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./H77 Pro4-M, BIOS P2.00 08/06/2013 Nov 30 14:10:10 Pithos kernel: 0000000000000000 ffff88044f283e18 ffffffff815f12b0 0000000000000001 Nov 30 14:10:10 Pithos kernel: ffff88043ca56a00 ffff88044f283e48 ffffffff8107b05f 0000000100006766 Nov 30 14:10:10 Pithos kernel: ffff88043ca56a00 0000000000000000 0000000000000010 ffff88044f283e88 Nov 30 14:10:10 Pithos kernel: Call Trace: Nov 30 14:10:10 Pithos kernel: <IRQ> [<ffffffff815f12b0>] dump_stack+0x4c/0x6e Nov 30 14:10:10 Pithos kernel: [<ffffffff8107b05f>] __report_bad_irq+0x2b/0xbe Nov 30 14:10:10 Pithos kernel: [<ffffffff8107b46a>] note_interrupt+0x19d/0x227 Nov 30 14:10:10 Pithos kernel: [<ffffffff81079460>] handle_irq_event_percpu+0xe0/0xf2 Nov 30 14:10:10 Pithos kernel: [<ffffffff810794ae>] handle_irq_event+0x3c/0x5e Nov 30 14:10:10 Pithos kernel: [<ffffffff8107bcc7>] handle_fasteoi_irq+0x7a/0xdb Nov 30 14:10:10 Pithos kernel: [<ffffffff8100cf66>] handle_irq+0x1a/0x24 Nov 30 14:10:10 Pithos kernel: [<ffffffff8108f5ca>] ? __tick_nohz_idle_enter+0x15a/0x308 Nov 30 14:10:10 Pithos kernel: [<ffffffff8100c9f8>] do_IRQ+0x49/0xcd Nov 30 14:10:10 Pithos kernel: [<ffffffff815f74ae>] common_interrupt+0x6e/0x6e Nov 30 14:10:10 Pithos kernel: <EOI> [<ffffffff814dd3ad>] ? cpuidle_enter_state+0xb9/0x114 Nov 30 14:10:10 Pithos kernel: [<ffffffff814dd343>] ? cpuidle_enter_state+0x4f/0x114 Nov 30 14:10:10 Pithos kernel: [<ffffffff814dd42a>] cpuidle_enter+0x12/0x14 Nov 30 14:10:10 Pithos kernel: [<ffffffff810728ac>] cpu_startup_entry+0x1e2/0x2b2 Nov 30 14:10:10 Pithos kernel: [<ffffffff810324d4>] start_secondary+0x10e/0x12c Nov 30 14:10:10 Pithos kernel: handlers: Nov 30 14:10:10 Pithos kernel: [<ffffffff81486040>] vfio_intx_handler Nov 30 14:10:10 Pithos kernel: [<ffffffff81486040>] vfio_intx_handler Nov 30 14:10:10 Pithos kernel: Disabling IRQ #16 Nov 30 14:10:18 Pithos logger: Waiting machines........................................ Nov 30 14:10:18 Pithos logger: The following machines are still running, forcing shutdown: Windows-10 Nov 30 14:10:18 Pithos logger: Nov 30 14:10:19 Pithos kernel: br0: port 4(vnet2) entered disabled state Nov 30 14:10:19 Pithos avahi-daemon[26230]: Withdrawing workstation service for vnet2. Nov 30 14:10:19 Pithos kernel: device vnet2 left promiscuous mode Nov 30 14:10:19 Pithos kernel: br0: port 4(vnet2) entered disabled state Nov 30 14:10:19 Pithos logger: Domain 06c9e45e-2bf5-9cf4-4ac1-6cce45fbcaaa destroyed Nov 30 14:10:19 Pithos logger: Nov 30 14:10:19 Pithos logger: Nov 30 14:10:21 Pithos logger: Stopping libvirtd... Nov 30 14:10:24 Pithos rc.unRAID[30194][31694]: Running: "/usr/local/emhttp/plugins/powerdown/event/stopping_svcs" Nov 30 14:10:24 Pithos rc.unRAID[31698][31702]: Processing /etc/rc.d/rc.unRAID.d/ kill services scripts. Nov 30 14:10:24 Pithos rc.unRAID[30194][31706]: Running: "/usr/local/emhttp/plugins/powerdown/event/unmounting_disks" Nov 30 14:10:24 Pithos rc.unRAID[31710][31715]: Processing /etc/rc.d/rc.unRAID.d/ kill scripts. Nov 30 14:10:24 Pithos rc.unRAID[31710][31719]: Running: "/etc/rc.d/rc.unRAID.d/K00.sh" Nov 30 14:10:42 Pithos rc.unRAID[31710][31722]: ssh: connect to host 192.168.00.83 port 22: No route to host#015 Nov 30 14:10:47 Pithos rc.unRAID[31710][31722]: error: failed to connect to the hypervisor Nov 30 14:10:47 Pithos rc.unRAID[31710][31722]: error: no valid connection Nov 30 14:10:47 Pithos rc.unRAID[31710][31722]: error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory Nov 30 14:10:47 Pithos K00.sh: Remote Shutdown OSX Machine Nov 30 14:10:47 Pithos rc.unRAID[30194][31753]: Running: "/usr/local/emhttp/plugins/unassigned.devices/event/unmounting_disks" Nov 30 14:10:49 Pithos kernel: XFS (sde1): Unmounting Filesystem Nov 30 14:10:49 Pithos kernel: XFS (sdi1): Unmounting Filesystem Nov 30 14:10:50 Pithos rc.unRAID[30194][31859]: Stopping unRAID. Nov 30 14:10:50 Pithos avahi-daemon[26230]: Got SIGTERM, quitting. Nov 30 14:10:50 Pithos avahi-dnsconfd[26239]: read(): EOF Nov 30 14:10:50 Pithos avahi-daemon[26230]: Leaving mDNS multicast group on interface virbr0.IPv4 with address 192.168.00.1. Nov 30 14:10:50 Pithos avahi-daemon[26230]: Leaving mDNS multicast group on interface docker0.IPv4 with address 172.17.42.1. Nov 30 14:10:50 Pithos avahi-daemon[26230]: Leaving mDNS multicast group on interface br0.IPv4 with address 192.168.00.80. Nov 30 14:10:50 Pithos avahi-daemon[26230]: avahi-daemon 0.6.31 exiting. Nov 30 14:10:51 Pithos rc.unRAID[30194][31884]: Killing active pids on the array drives Nov 30 14:10:51 Pithos rc.unRAID[30194][31887]: Specified filename /mnt/disk[12][1-9] does not exist. Nov 30 14:10:51 Pithos rc.unRAID[30194][31887]: USER PID ACCESS COMMAND Nov 30 14:10:51 Pithos rc.unRAID[30194][31887]: /mnt/user/MEDIA: root kernel mount /mnt/user Nov 30 14:10:51 Pithos rc.unRAID[30194][31887]: /mnt/user/PHOTOS: root kernel mount /mnt/user Nov 30 14:10:51 Pithos rc.unRAID[30194][31887]: /mnt/user/BACKUP: Nov 30 14:10:51 Pithos rc.unRAID[30194][31887]: root kernel mount /mnt/user Nov 30 14:10:51 Pithos rc.unRAID[30194][31887]: /mnt/user/VM BACKUP: root kernel mount /mnt/user Nov 30 14:10:51 Pithos rc.unRAID[30194][31887]: /mnt/user/docker: root kernel mount /mnt/user Nov 30 14:10:51 Pithos rc.unRAID[30194][31887]: /mnt/user/downloads: root kernel mount /mnt/user Nov 30 14:10:51 Pithos rc.unRAID[30194][31887]: /mnt/disk1: root kernel mount /mnt/disk1 Nov 30 14:10:51 Pithos rc.unRAID[30194][31887]: /mnt/disk2: root kernel mount /mnt/disk2 Nov 30 14:10:51 Pithos rc.unRAID[30194][31887]: /mnt/cache: root kernel mount /mnt/cache Nov 30 14:10:51 Pithos rc.unRAID[30194][31887]: /dev/md1: root kernel mount /mnt/disk1 Nov 30 14:10:51 Pithos rc.unRAID[30194][31887]: /dev/md2: root kernel mount /mnt/disk2 Nov 30 14:10:51 Pithos rc.unRAID[30194][31888]: Sync filesystems Nov 30 14:10:51 Pithos rc.unRAID[30194][31890]: Umounting the drives Nov 30 14:10:51 Pithos kernel: XFS (md1): Unmounting Filesystem Nov 30 14:10:51 Pithos rc.unRAID[30194][31894]: /dev/md1 has been unmounted Nov 30 14:10:51 Pithos kernel: XFS (md2): Unmounting Filesystem Nov 30 14:10:51 Pithos rc.unRAID[30194][31894]: /dev/md2 has been unmounted Nov 30 14:10:51 Pithos rc.unRAID[30194][31897]: Stopping the Array Nov 30 14:10:51 Pithos kernel: mdcmd (14): stop Nov 30 14:10:51 Pithos kernel: md1: stopping Nov 30 14:10:51 Pithos kernel: md2: stopping Nov 30 14:10:56 Pithos mdstatusdiff[31918]: --- /tmp/mdcmd.30194.1#0112015-11-30 14:10:51.727975947 -0600 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: +++ /tmp/mdcmd.30194.2#0112015-11-30 14:10:56.744976107 -0600 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: @@ -1,14 +1,14 @@ Nov 30 14:10:56 Pithos mdstatusdiff[31918]: sbName=/boot/config/super.dat Nov 30 14:10:56 Pithos mdstatusdiff[31918]: sbVersion=2.5.2 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: sbCreated=1444688593 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: -sbUpdated=1448913919 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: -sbEvents=136 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: -sbState=0 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: +sbUpdated=1448914251 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: +sbEvents=137 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: +sbState=1 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: sbNumDisks=3 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: sbSynced=1448114526 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: sbSyncErrs=0 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: mdVersion=2.5.3 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: -mdState=STARTED Nov 30 14:10:56 Pithos mdstatusdiff[31918]: +mdState=STOPPED Nov 30 14:10:56 Pithos mdstatusdiff[31918]: mdNumDisks=3 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: mdNumProtected=3 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: mdNumDisabled=0
November 30, 201510 yr Author Nov 30 14:08:58 Pithos powerdown[29990]: Powerdown initiated Nov 30 14:08:58 Pithos powerdown[29996]: Powerdown V2.18 Nov 30 14:08:58 Pithos rc.unRAID[30000][30004]: Processing /etc/rc.d/rc.unRAID.d/ kill services scripts. Nov 30 14:08:58 Pithos rc.unRAID[30008][30012]: Processing /etc/rc.d/rc.unRAID.d/ kill scripts. Nov 30 14:08:58 Pithos rc.unRAID[30008][30016]: Running: "/etc/rc.d/rc.unRAID.d/K00.sh" Nov 30 14:08:58 Pithos rc.unRAID[30008][30019]: Shutdown NOW! Nov 30 14:08:58 Pithos rc.unRAID[30008][30019]: #015 Nov 30 14:08:58 Pithos rc.unRAID[30008][30019]: System shutdown time has arrived#007#007#015 Nov 30 14:08:58 Pithos rc.unRAID[30008][30019]: Connection to 192.168.00.83 closed by remote host.#015 Nov 30 14:09:01 Pithos kernel: br0: port 3(vnet1) entered disabled state Nov 30 14:09:01 Pithos avahi-daemon[26230]: Withdrawing workstation service for vnet1. Nov 30 14:09:01 Pithos kernel: device vnet1 left promiscuous mode Nov 30 14:09:01 Pithos kernel: br0: port 3(vnet1) entered disabled state Nov 30 14:09:01 Pithos kernel: irq 16: nobody cared (try booting with the "irqpoll" option) Nov 30 14:09:01 Pithos kernel: CPU: 4 PID: 0 Comm: swapper/4 Not tainted 4.1.13-unRAID #1 Nov 30 14:09:01 Pithos kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./H77 Pro4-M, BIOS P2.00 08/06/2013 Nov 30 14:09:01 Pithos kernel: 0000000000000000 ffff88044f303e18 ffffffff815f12b0 0000000000000001 Nov 30 14:09:01 Pithos kernel: ffff88043ca56a00 ffff88044f303e48 ffffffff8107b05f 00000000ffff5cb3 Nov 30 14:09:01 Pithos kernel: ffff88043ca56a00 0000000000000000 0000000000000010 ffff88044f303e88 Nov 30 14:09:01 Pithos kernel: Call Trace: Nov 30 14:09:01 Pithos kernel: <IRQ> [<ffffffff815f12b0>] dump_stack+0x4c/0x6e Nov 30 14:09:01 Pithos kernel: [<ffffffff8107b05f>] __report_bad_irq+0x2b/0xbe Nov 30 14:09:01 Pithos kernel: [<ffffffff8107b46a>] note_interrupt+0x19d/0x227 Nov 30 14:09:01 Pithos kernel: [<ffffffff81079460>] handle_irq_event_percpu+0xe0/0xf2 Nov 30 14:09:01 Pithos kernel: [<ffffffff810794ae>] handle_irq_event+0x3c/0x5e Nov 30 14:09:01 Pithos kernel: [<ffffffff8107bcc7>] handle_fasteoi_irq+0x7a/0xdb Nov 30 14:09:01 Pithos kernel: [<ffffffff8100cf66>] handle_irq+0x1a/0x24 Nov 30 14:09:01 Pithos kernel: [<ffffffff8108f6ee>] ? __tick_nohz_idle_enter+0x27e/0x308 Nov 30 14:09:01 Pithos kernel: [<ffffffff8100c9f8>] do_IRQ+0x49/0xcd Nov 30 14:09:01 Pithos kernel: [<ffffffff815f74ae>] common_interrupt+0x6e/0x6e Nov 30 14:09:01 Pithos kernel: <EOI> [<ffffffff814dd3ad>] ? cpuidle_enter_state+0xb9/0x114 Nov 30 14:09:01 Pithos kernel: [<ffffffff814dd343>] ? cpuidle_enter_state+0x4f/0x114 Nov 30 14:09:01 Pithos kernel: [<ffffffff814dd42a>] cpuidle_enter+0x12/0x14 Nov 30 14:09:01 Pithos kernel: [<ffffffff810728ac>] cpu_startup_entry+0x1e2/0x2b2 Nov 30 14:09:01 Pithos kernel: [<ffffffff810324d4>] start_secondary+0x10e/0x12c Nov 30 14:09:01 Pithos kernel: handlers: Nov 30 14:09:01 Pithos kernel: [<ffffffff81486040>] vfio_intx_handler Nov 30 14:09:01 Pithos kernel: Disabling IRQ #16 Nov 30 14:09:03 Pithos K00.sh: Remote Shutdown OSX Machine Nov 30 14:09:03 Pithos powerdown[30143]: Initiating Shutdown with '-r' Nov 30 14:09:03 Pithos shutdown[30144]: shutting down for system reboot Nov 30 14:09:04 Pithos init: Switching to runlevel: 6 Nov 30 14:09:06 Pithos rc.unRAID[30194][30198]: Powerdown V2.18 Nov 30 14:09:06 Pithos rc.unRAID[30194][30202]: Stopping Plugins. Nov 30 14:09:06 Pithos rc.unRAID[30194][30203]: Running: "/usr/local/emhttp/plugins/dynamix.cache.dirs/event/stopping_svcs" Nov 30 14:09:06 Pithos cache_dirs: killing cache_dirs process 25964 Nov 30 14:09:06 Pithos rc.unRAID[30194][30222]: Running: "/usr/local/emhttp/plugins/dynamix.docker.manager/event/stopping_svcs" Nov 30 14:09:06 Pithos rc.unRAID[30194][30225]: Stopping Docker... Nov 30 14:09:06 Pithos logger: stopping docker ... Nov 30 14:09:06 Pithos logger: df36c7c88860 Nov 30 14:09:16 Pithos kernel: veth3fb2bf0: renamed from eth0 Nov 30 14:09:16 Pithos kernel: docker0: port 4(veth54a5240) entered disabled state Nov 30 14:09:16 Pithos kernel: docker0: port 4(veth54a5240) entered disabled state Nov 30 14:09:16 Pithos avahi-daemon[26230]: Withdrawing workstation service for veth3fb2bf0. Nov 30 14:09:16 Pithos avahi-daemon[26230]: Withdrawing workstation service for veth54a5240. Nov 30 14:09:16 Pithos kernel: device veth54a5240 left promiscuous mode Nov 30 14:09:16 Pithos kernel: docker0: port 4(veth54a5240) entered disabled state Nov 30 14:09:16 Pithos logger: 4e47417b44a6 Nov 30 14:09:17 Pithos emhttp: cmd: /usr/local/emhttp/plugins/dynamix/scripts/tail_log syslog Nov 30 14:09:26 Pithos kernel: vethd81503c: renamed from eth0 Nov 30 14:09:26 Pithos kernel: docker0: port 3(veth902a408) entered disabled state Nov 30 14:09:26 Pithos kernel: docker0: port 3(veth902a408) entered disabled state Nov 30 14:09:26 Pithos avahi-daemon[26230]: Withdrawing workstation service for vethd81503c. Nov 30 14:09:26 Pithos avahi-daemon[26230]: Withdrawing workstation service for veth902a408. Nov 30 14:09:26 Pithos kernel: device veth902a408 left promiscuous mode Nov 30 14:09:26 Pithos kernel: docker0: port 3(veth902a408) entered disabled state Nov 30 14:09:26 Pithos logger: 92fe79d45127 Nov 30 14:09:26 Pithos kernel: veth94f5539: renamed from eth0 Nov 30 14:09:26 Pithos kernel: docker0: port 2(vethb3f837a) entered disabled state Nov 30 14:09:26 Pithos kernel: docker0: port 2(vethb3f837a) entered disabled state Nov 30 14:09:26 Pithos avahi-daemon[26230]: Withdrawing workstation service for veth94f5539. Nov 30 14:09:26 Pithos avahi-daemon[26230]: Withdrawing workstation service for vethb3f837a. Nov 30 14:09:26 Pithos kernel: device vethb3f837a left promiscuous mode Nov 30 14:09:26 Pithos kernel: docker0: port 2(vethb3f837a) entered disabled state Nov 30 14:09:26 Pithos logger: 7354a5ccd338 Nov 30 14:09:26 Pithos kernel: veth61de4b4: renamed from eth0 Nov 30 14:09:26 Pithos kernel: docker0: port 1(veth6ea4e5d) entered disabled state Nov 30 14:09:26 Pithos kernel: docker0: port 1(veth6ea4e5d) entered disabled state Nov 30 14:09:26 Pithos avahi-daemon[26230]: Withdrawing workstation service for veth61de4b4. Nov 30 14:09:26 Pithos avahi-daemon[26230]: Withdrawing workstation service for veth6ea4e5d. Nov 30 14:09:26 Pithos kernel: device veth6ea4e5d left promiscuous mode Nov 30 14:09:26 Pithos kernel: docker0: port 1(veth6ea4e5d) entered disabled state Nov 30 14:09:26 Pithos logger: aac9293e44a5 Nov 30 14:09:27 Pithos logger: unmounting docker loopback Nov 30 14:09:28 Pithos rc.unRAID[30194][31218]: Running: "/usr/local/emhttp/plugins/dynamix.vm.manager/event/stopping_svcs" Nov 30 14:09:28 Pithos rc.unRAID[30194][31221]: Stopping libvirt... Nov 30 14:09:28 Pithos ntpd[1567]: Deleting interface #2 docker0, 172.17.42.1#123, interface stats: received=0, sent=0, dropped=0, active_time=239 secs Nov 30 14:09:33 Pithos logger: Domain fbf3f0fb-ec17-a43e-37f0-0a7d9f67f7a6 is being shutdown Nov 30 14:09:33 Pithos logger: Nov 30 14:09:34 Pithos kernel: br0: port 2(vnet0) entered disabled state Nov 30 14:09:34 Pithos kernel: device vnet0 left promiscuous mode Nov 30 14:09:34 Pithos kernel: br0: port 2(vnet0) entered disabled state Nov 30 14:09:34 Pithos avahi-daemon[26230]: Withdrawing workstation service for vnet0. Nov 30 14:09:38 Pithos logger: Domain 06c9e45e-2bf5-9cf4-4ac1-6cce45fbcaaa is being shutdown Nov 30 14:09:38 Pithos logger: Nov 30 14:10:10 Pithos kernel: irq 16: nobody cared (try booting with the "irqpoll" option) Nov 30 14:10:10 Pithos kernel: CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.1.13-unRAID #1 Nov 30 14:10:10 Pithos kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./H77 Pro4-M, BIOS P2.00 08/06/2013 Nov 30 14:10:10 Pithos kernel: 0000000000000000 ffff88044f283e18 ffffffff815f12b0 0000000000000001 Nov 30 14:10:10 Pithos kernel: ffff88043ca56a00 ffff88044f283e48 ffffffff8107b05f 0000000100006766 Nov 30 14:10:10 Pithos kernel: ffff88043ca56a00 0000000000000000 0000000000000010 ffff88044f283e88 Nov 30 14:10:10 Pithos kernel: Call Trace: Nov 30 14:10:10 Pithos kernel: <IRQ> [<ffffffff815f12b0>] dump_stack+0x4c/0x6e Nov 30 14:10:10 Pithos kernel: [<ffffffff8107b05f>] __report_bad_irq+0x2b/0xbe Nov 30 14:10:10 Pithos kernel: [<ffffffff8107b46a>] note_interrupt+0x19d/0x227 Nov 30 14:10:10 Pithos kernel: [<ffffffff81079460>] handle_irq_event_percpu+0xe0/0xf2 Nov 30 14:10:10 Pithos kernel: [<ffffffff810794ae>] handle_irq_event+0x3c/0x5e Nov 30 14:10:10 Pithos kernel: [<ffffffff8107bcc7>] handle_fasteoi_irq+0x7a/0xdb Nov 30 14:10:10 Pithos kernel: [<ffffffff8100cf66>] handle_irq+0x1a/0x24 Nov 30 14:10:10 Pithos kernel: [<ffffffff8108f5ca>] ? __tick_nohz_idle_enter+0x15a/0x308 Nov 30 14:10:10 Pithos kernel: [<ffffffff8100c9f8>] do_IRQ+0x49/0xcd Nov 30 14:10:10 Pithos kernel: [<ffffffff815f74ae>] common_interrupt+0x6e/0x6e Nov 30 14:10:10 Pithos kernel: <EOI> [<ffffffff814dd3ad>] ? cpuidle_enter_state+0xb9/0x114 Nov 30 14:10:10 Pithos kernel: [<ffffffff814dd343>] ? cpuidle_enter_state+0x4f/0x114 Nov 30 14:10:10 Pithos kernel: [<ffffffff814dd42a>] cpuidle_enter+0x12/0x14 Nov 30 14:10:10 Pithos kernel: [<ffffffff810728ac>] cpu_startup_entry+0x1e2/0x2b2 Nov 30 14:10:10 Pithos kernel: [<ffffffff810324d4>] start_secondary+0x10e/0x12c Nov 30 14:10:10 Pithos kernel: handlers: Nov 30 14:10:10 Pithos kernel: [<ffffffff81486040>] vfio_intx_handler Nov 30 14:10:10 Pithos kernel: [<ffffffff81486040>] vfio_intx_handler Nov 30 14:10:10 Pithos kernel: Disabling IRQ #16 Nov 30 14:10:18 Pithos logger: Waiting machines........................................ Nov 30 14:10:18 Pithos logger: The following machines are still running, forcing shutdown: Windows-10 Nov 30 14:10:18 Pithos logger: Nov 30 14:10:19 Pithos kernel: br0: port 4(vnet2) entered disabled state Nov 30 14:10:19 Pithos avahi-daemon[26230]: Withdrawing workstation service for vnet2. Nov 30 14:10:19 Pithos kernel: device vnet2 left promiscuous mode Nov 30 14:10:19 Pithos kernel: br0: port 4(vnet2) entered disabled state Nov 30 14:10:19 Pithos logger: Domain 06c9e45e-2bf5-9cf4-4ac1-6cce45fbcaaa destroyed Nov 30 14:10:19 Pithos logger: Nov 30 14:10:19 Pithos logger: Nov 30 14:10:21 Pithos logger: Stopping libvirtd... Nov 30 14:10:24 Pithos rc.unRAID[30194][31694]: Running: "/usr/local/emhttp/plugins/powerdown/event/stopping_svcs" Nov 30 14:10:24 Pithos rc.unRAID[31698][31702]: Processing /etc/rc.d/rc.unRAID.d/ kill services scripts. Nov 30 14:10:24 Pithos rc.unRAID[30194][31706]: Running: "/usr/local/emhttp/plugins/powerdown/event/unmounting_disks" Nov 30 14:10:24 Pithos rc.unRAID[31710][31715]: Processing /etc/rc.d/rc.unRAID.d/ kill scripts. Nov 30 14:10:24 Pithos rc.unRAID[31710][31719]: Running: "/etc/rc.d/rc.unRAID.d/K00.sh" Nov 30 14:10:42 Pithos rc.unRAID[31710][31722]: ssh: connect to host 192.168.00.83 port 22: No route to host#015 Nov 30 14:10:47 Pithos rc.unRAID[31710][31722]: error: failed to connect to the hypervisor Nov 30 14:10:47 Pithos rc.unRAID[31710][31722]: error: no valid connection Nov 30 14:10:47 Pithos rc.unRAID[31710][31722]: error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory Nov 30 14:10:47 Pithos K00.sh: Remote Shutdown OSX Machine Nov 30 14:10:47 Pithos rc.unRAID[30194][31753]: Running: "/usr/local/emhttp/plugins/unassigned.devices/event/unmounting_disks" Nov 30 14:10:49 Pithos kernel: XFS (sde1): Unmounting Filesystem Nov 30 14:10:49 Pithos kernel: XFS (sdi1): Unmounting Filesystem Nov 30 14:10:50 Pithos rc.unRAID[30194][31859]: Stopping unRAID. Nov 30 14:10:50 Pithos avahi-daemon[26230]: Got SIGTERM, quitting. Nov 30 14:10:50 Pithos avahi-dnsconfd[26239]: read(): EOF Nov 30 14:10:50 Pithos avahi-daemon[26230]: Leaving mDNS multicast group on interface virbr0.IPv4 with address 192.168.00.1. Nov 30 14:10:50 Pithos avahi-daemon[26230]: Leaving mDNS multicast group on interface docker0.IPv4 with address 172.17.42.1. Nov 30 14:10:50 Pithos avahi-daemon[26230]: Leaving mDNS multicast group on interface br0.IPv4 with address 192.168.00.80. Nov 30 14:10:50 Pithos avahi-daemon[26230]: avahi-daemon 0.6.31 exiting. Nov 30 14:10:51 Pithos rc.unRAID[30194][31884]: Killing active pids on the array drives Nov 30 14:10:51 Pithos rc.unRAID[30194][31887]: Specified filename /mnt/disk[12][1-9] does not exist. Nov 30 14:10:51 Pithos rc.unRAID[30194][31887]: USER PID ACCESS COMMAND Nov 30 14:10:51 Pithos rc.unRAID[30194][31887]: /mnt/user/MEDIA: root kernel mount /mnt/user Nov 30 14:10:51 Pithos rc.unRAID[30194][31887]: /mnt/user/PHOTOS: root kernel mount /mnt/user Nov 30 14:10:51 Pithos rc.unRAID[30194][31887]: /mnt/user/BACKUP: Nov 30 14:10:51 Pithos rc.unRAID[30194][31887]: root kernel mount /mnt/user Nov 30 14:10:51 Pithos rc.unRAID[30194][31887]: /mnt/user/VM BACKUP: root kernel mount /mnt/user Nov 30 14:10:51 Pithos rc.unRAID[30194][31887]: /mnt/user/docker: root kernel mount /mnt/user Nov 30 14:10:51 Pithos rc.unRAID[30194][31887]: /mnt/user/downloads: root kernel mount /mnt/user Nov 30 14:10:51 Pithos rc.unRAID[30194][31887]: /mnt/disk1: root kernel mount /mnt/disk1 Nov 30 14:10:51 Pithos rc.unRAID[30194][31887]: /mnt/disk2: root kernel mount /mnt/disk2 Nov 30 14:10:51 Pithos rc.unRAID[30194][31887]: /mnt/cache: root kernel mount /mnt/cache Nov 30 14:10:51 Pithos rc.unRAID[30194][31887]: /dev/md1: root kernel mount /mnt/disk1 Nov 30 14:10:51 Pithos rc.unRAID[30194][31887]: /dev/md2: root kernel mount /mnt/disk2 Nov 30 14:10:51 Pithos rc.unRAID[30194][31888]: Sync filesystems Nov 30 14:10:51 Pithos rc.unRAID[30194][31890]: Umounting the drives Nov 30 14:10:51 Pithos kernel: XFS (md1): Unmounting Filesystem Nov 30 14:10:51 Pithos rc.unRAID[30194][31894]: /dev/md1 has been unmounted Nov 30 14:10:51 Pithos kernel: XFS (md2): Unmounting Filesystem Nov 30 14:10:51 Pithos rc.unRAID[30194][31894]: /dev/md2 has been unmounted Nov 30 14:10:51 Pithos rc.unRAID[30194][31897]: Stopping the Array Nov 30 14:10:51 Pithos kernel: mdcmd (14): stop Nov 30 14:10:51 Pithos kernel: md1: stopping Nov 30 14:10:51 Pithos kernel: md2: stopping Nov 30 14:10:56 Pithos mdstatusdiff[31918]: --- /tmp/mdcmd.30194.1#0112015-11-30 14:10:51.727975947 -0600 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: +++ /tmp/mdcmd.30194.2#0112015-11-30 14:10:56.744976107 -0600 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: @@ -1,14 +1,14 @@ Nov 30 14:10:56 Pithos mdstatusdiff[31918]: sbName=/boot/config/super.dat Nov 30 14:10:56 Pithos mdstatusdiff[31918]: sbVersion=2.5.2 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: sbCreated=1444688593 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: -sbUpdated=1448913919 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: -sbEvents=136 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: -sbState=0 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: +sbUpdated=1448914251 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: +sbEvents=137 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: +sbState=1 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: sbNumDisks=3 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: sbSynced=1448114526 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: sbSyncErrs=0 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: mdVersion=2.5.3 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: -mdState=STARTED Nov 30 14:10:56 Pithos mdstatusdiff[31918]: +mdState=STOPPED Nov 30 14:10:56 Pithos mdstatusdiff[31918]: mdNumDisks=3 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: mdNumProtected=3 Nov 30 14:10:56 Pithos mdstatusdiff[31918]: mdNumDisabled=0 Can you post your K00.sh? It appears that the powerdown script restarted in the middle of the K00.sh execution. You also had an irg16 issue creating a call trace fault which is making your log confusing. Has the K00.sh script worked for you before or are you just now trying to get it going?
December 1, 201510 yr Can you post your K00.sh? It appears that the powerdown script restarted in the middle of the K00.sh execution. K00.sh ssh [email protected] sudo shutdown -h now You also had an irg16 issue creating a call trace fault which is making your log confusing. Not sure what is causing this but it seems to always happen when I reboot unRAID Has the K00.sh script worked for you before or are you just now trying to get it going? This is the first time I have created a K00.sh script. I have a couple of S0#.sh scripts that work.
December 9, 201510 yr Hi dlandon, would it be possible to implement some special handling for cachedirs to make sure clean shutdown when cachedirs is still having active child processes (finds). It occurs to me every now and then (...and I would think for others as well) that I need to stop the array shortly after booting up. Now when cachedirs is still having active 'find' processes, unmounting of the disks are not possible and I either need to wait a couple of minutes until the active find processes finish or I need to telnet in and kill them manually. Would that be somehow possible by the powerdown plugin? Thank you for the help (and for the great plugin) in advance!
December 9, 201510 yr Author The best way to handle this is by cache_dirs stopping all its child processes. I have also noticed this behavior. Cache_dirs is supposed to stop all the child processes when it quits, but I question whether or not that is happening. I'll spend a few minutes looking at the Dynamix plugin and see what it is doing to stop cache_dirs and see if there is anything I can suggest.
December 9, 201510 yr I've put this in my K00.sh to kill all cache_dirs related: killall cache_dirs killall find
December 9, 201510 yr Author I've put this in my K00.sh to kill all cache_dirs related: killall cache_dirs killall find While this approach might be effective, you should not have to write a special kill script to get cache_dirs to behave. Highlighting a plugin issue like this is the main reason powerdown does not take the 'brute force" approach to shutting down the array. Plugins should behave as expected. I've done some testing and have made some suggestions to Bonienl for the rc.cachedirs script to be sure the child processes stop in a reasonable time. The issue causing this problem is that the child 'find' processes take quite a while to stop and the rc.cachedirs script doesn't wait long enough for them to stop. This gives the impression that cache_dirs is completely stopped when it is not and the array is shut down unclean.
December 9, 201510 yr Many thanks dlandon for looking at this! I actually don't use the cache_dirs plugin, but the original script started from the "go" file. If I understand correctly your suggestions to Bonienl, if he was implementing those, one would need to use the plugin to get it right, is that correct? Also, my understanding is that you are proposing to wait until all child 'find' processes stop regardless of how much time this will take. This would mean _minutes_ would be spent only to wait these processes to stop. Wasn't there a solution to get those stop immediately? I tend to go with the solution ICDeadPpl suggested if there is no harm, but I believe there is no?
December 9, 201510 yr Author Many thanks dlandon for looking at this! I actually don't use the cache_dirs plugin, but the original script started from the "go" file. If I understand correctly your suggestions to Bonienl, if he was implementing those, one would need to use the plugin to get it right, is that correct? Also, my understanding is that you are proposing to wait until all child 'find' processes stop regardless of how much time this will take. This would mean _minutes_ would be spent only to wait these processes to stop. Wasn't there a solution to get those stop immediately? I tend to go with the solution ICDeadPpl suggested if there is no harm, but I believe there is no? If you are on V6, why not use the plugin? Actually my proposal to Bonienl is to kill the 'find' processes and not wait for them. You are right they can take minutes to stop on their own. I did a test on my server by starting the array and then immediately stopping cache_dirs and it took about 3 minutes for all the 'find' child processes to stop. When I implemented my suggested fix, the child processes were stopped immediately. Other than the fact that you should not have to force cache_dirs to stop, I don't see an issue with the suggestion to stop cache_dirs except any other 'find' processes not belonging to cache_dirs would also be stopped.
December 9, 201510 yr If you are on V6, why not use the plugin? Good question. I think it is more for sentimental reasons; out of respect to Joe L. ...but you are right, probably it's time to move on. Actually my proposal to Bonienl is to kill the 'find' processes and not wait for them. You are right they can take minutes to stop on their own. I did a test on my server by starting the array and then immediately stopping cache_dirs and it took about 3 minutes for all the 'find' child processes to stop. When I implemented my suggested fix, the child processes were stopped immediately. Great! Thank you for your support once again! Let's cross the fingers to get your proposals in by Bonienl. I guess it is the cache_dirs plugin what will need to be amended? I am now using the K script approach as a workaround and it works well! Thanks ICDeadPpl for suggesting this! Another slightly related question: how do you start it again on "Start"? I tried to use an S script for that (same command I had in the go file), but actually the array was hanging on start and I had to remove the S script and reboot.
December 9, 201510 yr Author If you are on V6, why not use the plugin? Good question. I think it is more for sentimental reasons; out of respect to Joe L. ...but you are right, probably it's time to move on. Actually my proposal to Bonienl is to kill the 'find' processes and not wait for them. You are right they can take minutes to stop on their own. I did a test on my server by starting the array and then immediately stopping cache_dirs and it took about 3 minutes for all the 'find' child processes to stop. When I implemented my suggested fix, the child processes were stopped immediately. Great! Thank you for your support once again! Let's cross the fingers to get your proposals in by Bonienl. I guess it is the cache_dirs plugin what will need to be amended? I am now using the K script approach as a workaround and it works well! Thanks ICDeadPpl for suggesting this! Another slightly related question: how do you start it again on "Start"? I tried to use an S script for that (same command I had in the go file), but actually the array was hanging on start and I had to remove the S script and reboot. Cache_dirs plugin has been updated. The modification is in the rc.cachedirs script that controls the stopping of cache_dirs. Rather than waiting for the 'find' child processes to stop, they are now killed as they are found. No changes have been made to the cache_dirs script. I just started my test server, logged in immediately when it had started on the console, and typed 'reboot'. I got a clean shutdown. Drop the go script changes and install the cache_dirs plugin. All parameter settings and start/stop control is done in the webgui. The cache_dirs plugin starts and stops cache_dirs at the proper array events. It is easier, less prone to errors, and is updated and maintained by Bonienl. Making modifications to the go script in V6 is highly discouraged. There are plugins that will let you do the things that were done in the go script in V5.
December 10, 201510 yr OK, I take you advice to move on and use the plugin. I just tested it, but killing child 'find' processes still doesn't seems to happen. Apparently the cache_dirs process gets killed, so unmounting occurs after the active find process finishes. However, if it is a long one, then it can still take a lot of time before unmounting is possible. I understood from you that the active child 'find' processes should be killed by now as well and not only cache_dirs itself? What I was doing for testing is that I tried to stop the array immediately after booting up (so the finds were still active). Thank you for your help on this! ...shall we actually move/ continue discussing this in the cache_dirs thread? Do you also have some hints how could cache_dirs be started on array start? I mean not during boot, because that's working fine, but during manual start after manual stop.
December 10, 201510 yr Author OK, I take you advice to move on and use the plugin. I just tested it, but killing child 'find' processes still doesn't seems to happen. Apparently the cache_dirs process gets killed, so unmounting occurs after the active find process finishes. However, if it is a long one, then it can still take a lot of time before unmounting is possible. I understood from you that the active child 'find' processes should be killed by now as well and not only cache_dirs itself? Do you have the latest plugin installed? What is a lot of time? How do you know it's the child processes of cache_dirs? Did you get a clean shutdown? Post the log from this shutdown. What I was doing for testing is that I tried to stop the array immediately after booting up (so the finds were still active). I did this and it worked perfectly. Thank you for your help on this! ...shall we actually move/ continue discussing this in the cache_dirs thread? Here is fine. Do you also have some hints how could cache_dirs be started on array start? I mean not during boot, because that's working fine, but during manual start after manual stop. The plugin is handling this. You don't need to do anything. The cache_dirs forum is the best place to get information about starting cache_dirs. If you want to do additional troubleshooting there is a plugin that can help. Install this plugin http://lime-technology.com/forum/index.php?topic=42881.0 and follow the troubleshooting procedure to see what files are left open preventing a shutdown.
December 10, 201510 yr Do you have the latest plugin installed? What is a lot of time? How do you know it's the child processes of cache_dirs? Did you get a clean shutdown? Post the log from this shutdown. Yes, I just installed the plugin so couldn't even have older version I haven't tried shutdown or reboot; I actually only tried to manually stop the array from the UI. I understood it should work also in this case? Or only at shutdown and reboot? ...but if I have the K script with forced kill of finds, then it's OK even only on manual stop via UI without shutdown or reboot. Knowing what is holding back the un-mounting is easy and fully clear. I perform a 'ps -ef' from the console and I still see the actual child 'find' process running. The situation is definitely better than before, because before the update even cache_dirs was still running which is not the case now - maybe that's why you experience better behavior now. In case you stop/shutdown at a time when the child 'find' process is processing a smaller dir, then it finish relatively quickly and un-mounting occurs. However, in case you perform stop/shutdown in case finds processing a large dir (e.g. in my case "Music") in the moment, then you can clearly see the find process doesn't get killed. The plugin is handling this. You don't need to do anything. The cache_dirs forum is the best place to get information about starting cache_dirs. Strange, if I stop the array manually and cache_dirs get killed, it doesn't get restarted for me when I start the array manually. I will raise this in the cache_dirs forum. If you want to do additional troubleshooting there is a plugin that can help. Install this plugin http://lime-technology.com/forum/index.php?topic=42881.0 and follow the troubleshooting procedure to see what files are left open preventing a shutdown. Would that be still needed in the above described case? For me it is clear it is the child 'find' process. If I kill that process manually from the console, un-mounting occurs immediately. Thanks for the support again!
December 10, 201510 yr Author Do you have the latest plugin installed? What is a lot of time? How do you know it's the child processes of cache_dirs? Did you get a clean shutdown? Post the log from this shutdown. Yes, I just installed the plugin so couldn't even have older version I haven't tried shutdown or reboot; I actually only tried to manually stop the array from the UI. I understood it should work also in this case? Or only at shutdown and reboot? ...but if I have the K script with forced kill of finds, then it's OK even only on manual stop via UI without shutdown or reboot. Knowing what is holding back the un-mounting is easy and fully clear. I perform a 'ps -ef' from the console and I still see the actual child 'find' process running. The situation is definitely better than before, because before the update even cache_dirs was still running which is not the case now - maybe that's why you experience better behavior now. In case you stop/shutdown at a time when the child 'find' process is processing a smaller dir, then it finish relatively quickly and un-mounting occurs. However, in case you perform stop/shutdown in case finds processing a large dir (e.g. in my case "Music") in the moment, then you can clearly see the find process doesn't get killed. The plugin is handling this. You don't need to do anything. The cache_dirs forum is the best place to get information about starting cache_dirs. Strange, if I stop the array manually and cache_dirs get killed, it doesn't get restarted for me when I start the array manually. I will raise this in the cache_dirs forum. If you want to do additional troubleshooting there is a plugin that can help. Install this plugin http://lime-technology.com/forum/index.php?topic=42881.0 and follow the troubleshooting procedure to see what files are left open preventing a shutdown. Would that be still needed in the above described case? For me it is clear it is the child 'find' process. If I kill that process manually from the console, un-mounting occurs immediately. Thanks for the support again! You did not answer my question. How much time is it taking? It is reasonable that it would take a few seconds. You are potentially making this situation worse with your K and S scripts. Please remove them and let the plugin do what it is intended to do. The cache_dirs plugin will start the cache_dirs script on the 'disks_mounted' event and stop the cache_dirs script on the 'stopping_svcs' event. If you want me to help you any further, you will need to start the array and then immediately initiate a reboot and post the log. I won't help you with your hacking up K and S scripts because you think the cache_dirs plugin is not doing what you like.
December 10, 201510 yr You did not answer my question. How much time is it taking? It is reasonable that it would take a few seconds. You are potentially making this situation worse with your K and S scripts. Please remove them and let the plugin do what it is intended to do. The cache_dirs plugin will start the cache_dirs script on the 'disks_mounted' event and stop the cache_dirs script on the 'stopping_svcs' event. If you want me to help you any further, you will need to start the array and then immediately initiate a reboot and post the log. I won't help you with your hacking up K and S scripts because you think the cache_dirs plugin is not doing what you like. Uhm, this hurts! I think I well described the situation and I hope this is just bad mood today rather than thinking I am doing stupid things here. Please take into consideration that I am not a newbie and not totally dumb either. I understand the frustration of supporting users who might know what they are using/doing and their setup is full hackery, but I am not that (type of) guy... To clarify: I have NO K or S script at all and I am testing this with a full clean setup. I was only referencing what happens IF actually there is a K script for force killing. To also answer the question: it takes minutes for find to process my music directory. It doesn't get killed. It stays there fully active and un-mounting only occurs when the child find process finished after those few minutes. I will post the log shortly.
December 10, 201510 yr Author Here is the process I want to use to troubleshoot your issues: - Get a log of a startup and immediate shutdown so I can see specifically what is happening. - Get the cache_dirs plugin starting and stopping correctly in your situation. - I will then have you do a test starting and stopping the array through the gui with a modified rc.cachedirs script. I have an idea of what might be happening in your situation. I will do some testing here and give you an updated rc.cachedirs script to try starting and stopping of the array. Please follow along with me on this one step at a time. When you do multiple things and bring in multiple ideas, it makes it hard to get a grasp on your problem.
December 10, 201510 yr OK, sure, here we go: The situation seems to be definitely different in case of reboot/shutdown and stopping the array. As per your request I initiated a reboot immediately after boot up and the shutdown went quickly and cleanly in a few seconds. However, if I just stop the array without shutting down or rebooting, the child 'find' process stays hanging there as described above. I know you don't like me guessing, but I presume on reboot actually the powerdown plugin did the killing of the 'child' find process instead of cache_dirs doing it on its own? Not sure how helpful the logs will be here as there is nothing specific about the killings in them, but I attached logs for both situations. I hope it tells more to you than for me... I think you will figure, but the earlier is about the rebooting, the latter is about the stopping exercise. tower-syslog-20151210-1334.zip tower-syslog-20151210-1345.zip
December 10, 201510 yr Author OK, sure, here we go: The situation seems to be definitely different in case of reboot/shutdown and stopping the array. As per your request I initiated a reboot immediately after boot up and the shutdown went quickly and cleanly in a few seconds. However, if I just stop the array without shutting down or rebooting, the child 'find' process stays hanging there as described above. I know you don't like me guessing, but I presume on reboot actually the powerdown plugin did the killing of the 'child' find process instead of cache_dirs doing it on its own? Not sure how helpful the logs will be here as there is nothing specific about the killings in them, but I attached logs for both situations. I hope it tells more to you than for me... I think you will figure, but the earlier is about the rebooting, the latter is about the stopping exercise. Copy this script file: #!/bin/sh program=cache_dirs execute=/usr/local/emhttp/plugins/dynamix.cache.dirs/scripts/$program options=/etc/$program.conf pid=$(pidof -s -x $execute) run=/tmp/$program.run case "$1" in 'start') if [ -z "$pid" ]; then echo "$execute $(cat $options) 2>/dev/null" >$run source $run rm -f $run echo "$program started" else echo "$program already running!" fi ;; 'stop') if [ -n "$pid" ]; then $execute -q 1>/dev/null 2>&1 timer=100 until [ -z "$(pidof -s -x $execute)" ] || [ $timer -eq 0 ]; do kill $(pidof -s -x $execute) timer=$((timer-1)) sleep 0.1 done echo "$program stopped" else echo "$program not running!" fi ;; *) echo "Usage: $(basename $0) start|stop" esac to /usr/local/emhttp/plugins/dynamix.cache.dirs/scripts/rc.cachedirs and try the start and stop of the array through the gui.
December 10, 201510 yr Copy this script file: #!/bin/sh program=cache_dirs execute=/usr/local/emhttp/plugins/dynamix.cache.dirs/scripts/$program options=/etc/$program.conf pid=$(pidof -s -x $execute) run=/tmp/$program.run case "$1" in 'start') if [ -z "$pid" ]; then echo "$execute $(cat $options) 2>/dev/null" >$run source $run rm -f $run echo "$program started" else echo "$program already running!" fi ;; 'stop') if [ -n "$pid" ]; then $execute -q 1>/dev/null 2>&1 timer=100 until [ -z "$(pidof -s -x $execute)" ] || [ $timer -eq 0 ]; do kill $(pidof -s -x $execute) timer=$((timer-1)) sleep 0.1 done echo "$program stopped" else echo "$program not running!" fi ;; *) echo "Usage: $(basename $0) start|stop" esac to /usr/local/emhttp/plugins/dynamix.cache.dirs/scripts/rc.cachedirs and try the start and stop of the array through the gui. WOW, that was quick, thank you for picking this up and working on it. Unfortunately exactly the same thing is happening with this script. Is there any detail I can provide you to help? Seems like I have to take back the starting part though. Cache_dirs is actually starting now on array start. Weird, I don't think you modified that part, so I am not sure why it was not working before. I have to admit I was not doing long testing and I might have fired too quick on this.
December 10, 201510 yr Author Just to confirm, you didn't reboot? I can't do it right now, but let me create some logging in that script so I can see what it it doing and give you another script to try.
December 10, 201510 yr Just to confirm, you didn't reboot? I can't do it right now, but let me create some logging in that script so I can see what it it doing and give you another script to try. No, I didn't. I am aware the adjustments wouldn't been disappeared
December 10, 201510 yr Author Just to confirm, you didn't reboot? I can't do it right now, but let me create some logging in that script so I can see what it it doing and give you another script to try. No, I didn't. I am aware the adjustments wouldn't been disappeared Try this: /usr/local/emhttp/plugins/dynamix.cache.dirs/scripts/rc.cachedirs stop and tell me how long it runs. This will stop cache_dirs with nothing else happening.
December 10, 201510 yr Try this: /usr/local/emhttp/plugins/dynamix.cache.dirs/scripts/rc.cachedirs stop and tell me how long it runs. This will stop cache_dirs with nothing else happening. Not sure how to answer The script runs and it stops cache_dirs immediately. I also get back the prompt immediately. However, 'ps -ef | grep find' shows the actual child 'find' process is still running and finishes when it finishes depending on how large is the dir. So killing cache_dirs works like a charm, but the sub-process stays there (PPID changes to 1 after parent has gone) and does not get killed.
December 10, 201510 yr Author Try this: /usr/local/emhttp/plugins/dynamix.cache.dirs/scripts/rc.cachedirs stop and tell me how long it runs. This will stop cache_dirs with nothing else happening. Not sure how to answer The script runs and it stops cache_dirs immediately. I also get back the prompt immediately. However, 'ps -ef | grep find' shows the actual child 'find' process is still running and finishes when it finishes depending on how large is the dir. So killing cache_dirs works like a charm, but the sub-process stays there (PPID changes to 1 after parent has gone) and does not get killed. Based on your quick test, there is nothing more I can do. You should post this issue on the cache_dirs discussion and see if Joe L. the creator of the cache_dirs script can add a more robust shutdown to the cache_dirs script.
Archived
This topic is now archived and is closed to further replies.