Helmonder

Mmm.... Did some more searching...: https://www.linuxquestions.org/questions/linux-security-4/kernel-device-eth0-entered-promiscuous-mode-756884/ As explained before promiscuous mode means a packet sniffer instructed your ethernet device to listen to all traffic. This can be a benign or a malicious act, but usually you will know if you run an application that provides you with traffic statistics (say ntop or vnstat) or an IDS (say Snort, Prelude, tcpdump or wireshark) or Something Else (say a DHCP client which isn't promiscuous mode but could be identified as one). Reviewing your installed packages might turn up valid applications that fit the above categories. Else, if an interface is (still) in promiscuous mode (old or new style) then running 'ip link show' will show the "PROMISC" tag and when a sniffer is not hidden then running Chkrootkit or Rootkit Hunter (or both) should show details about applications. If none of the above returns satisfying results then a more thorough inspection of the system is warranted (regardless the time between promisc mode switching as posted above being ridiculously short). In my case I do not expect that there is something bad going on... Question is however, is this "promiscuous mode" triggered by an individual docker (and is that docker maybe "bad"), or is this mode triggered by unraid in combination with the docker mechanism, and if so: why .. So I checked... Starting any docker on my system will imediately trigger "promiscuous mode" to be on... It does not matter what docker it is.. So that points to unraid doing something there.. I checked my log file: Apr 28 07:07:27 Tower rc.inet1: ip link set bond0 promisc on master br0 up Apr 28 07:07:27 Tower kernel: device bond0 entered promiscuous mode Apr 28 07:07:30 Tower kernel: device eth1 entered promiscuous mode Apr 28 07:08:10 Tower kernel: device br0 entered promiscuous mode pr 28 07:08:12 Tower kernel: device virbr0-nic entered promiscuous mode The promiscuous mode is related to network bonding, which is what I am using.. I find some info on it in combination with changing a VLAN's hardware address: https://wiki.linuxfoundation.org/networking/bonding Note that changing a VLAN interface's HW address would set the underlying device – i.e. the bonding interface – to promiscuous mode, which might not be what you want. I am going to stop digging as I am completely out of my comfort zone... And into some kind of rabbithole, maybe this promiscous mode has nothing to do with the issue.. Anyone ?

The last few lines in the log now show: Apr 28 11:27:35 Tower kernel: vetha56c284: renamed from eth0 Apr 28 11:27:47 Tower kernel: device br0 left promiscuous mode Apr 28 11:27:47 Tower kernel: veth3808ad4: renamed from eth0 The "renamed from eth0" point to the two Dockers stopping, the "device br0 left promiscuous mode" I googled a bit and read that "promiscuous mode" is most likely activated when some kind of traffic monitoring / sniffering is going on.. Is there something resembling that active in combination with Dockers in unraid ?

I am seeing code traces in the current log (so at this time): Apr 28 11:08:45 Tower kernel: Call Trace: Apr 28 11:08:45 Tower kernel: <IRQ> Apr 28 11:08:45 Tower kernel: ipv4_confirm+0xaf/0xb7 Apr 28 11:08:45 Tower kernel: nf_hook_slow+0x37/0x96 Apr 28 11:08:45 Tower kernel: ip_local_deliver+0xa7/0xd5 Apr 28 11:08:45 Tower kernel: ? ip_sublist_rcv_finish+0x53/0x53 Apr 28 11:08:45 Tower kernel: ip_rcv+0x9e/0xbc Apr 28 11:08:45 Tower kernel: ? ip_rcv_finish_core.isra.0+0x2e5/0x2e5 Apr 28 11:08:45 Tower kernel: __netif_receive_skb_one_core+0x4d/0x69 Apr 28 11:08:45 Tower kernel: process_backlog+0x7e/0x116 Apr 28 11:08:45 Tower kernel: net_rx_action+0x10b/0x274 Apr 28 11:08:45 Tower kernel: __do_softirq+0xce/0x1e2 Apr 28 11:08:45 Tower kernel: do_softirq_own_stack+0x2a/0x40 Apr 28 11:08:45 Tower kernel: </IRQ> Apr 28 11:08:45 Tower kernel: do_softirq+0x4d/0x59 Apr 28 11:08:45 Tower kernel: netif_rx_ni+0x1c/0x22 Apr 28 11:08:45 Tower kernel: macvlan_broadcast+0x10f/0x153 [macvlan] Apr 28 11:08:45 Tower kernel: macvlan_process_broadcast+0xd5/0x131 [macvlan] Apr 28 11:08:45 Tower kernel: process_one_work+0x16e/0x24f Apr 28 11:08:45 Tower kernel: ? pwq_unbound_release_workfn+0xb7/0xb7 Apr 28 11:08:45 Tower kernel: worker_thread+0x1dc/0x2ac Apr 28 11:08:45 Tower kernel: kthread+0x10b/0x113 Apr 28 11:08:45 Tower kernel: ? kthread_park+0x71/0x71 Apr 28 11:08:45 Tower kernel: ret_from_fork+0x35/0x40 Apr 28 11:08:45 Tower kernel: ---[ end trace c12044621539eec0 ]--- This seems to correspond with "macvlan" as discussed in the following post: https://forums.unraid.net/topic/75175-macvlan-call-traces/ Maybe tonight I experienced a kernel panic as a result of this Macvlan issue ? Weird though.. Server has been stable for weeks... So maybe there is some combination going on with the amount of disk traffic the parity rebuild was causing ? In the days before the parity rebuild I had two WD red's 10TB doing a preclear.. That did not cause an issue... So the parity sync might be the thing that pushes something over the edge.. I actually allready closed down all of my dockers but for Pihole and the HA-Bridge for Domoticz.. I turned those off also now... Since there is no docker with its own ip address running anymore now I would expect the errors to go away now..

System has come up again with invalid parity, it also restartes parity sync / data rebuild. The notification in the gui told me that parity sync was completed succesfully (ofcourse this wasn';t the case, seperate issue in the notification system). The preclear was stopped but could be resumed (restarted the post-read phase) I do not know if it is valuable but I included the current syslog. I also checked to logrotation but the previous one is five days old, so that will not help. Added: all dockers show update ready, does not seem correct, this was not the case yesterday. I have now stopped all dockers to give the array some rest during the parity rebuild syslog

I will now restart the array, it is not responding to anything

Lifesaver, worked for me also !

if grep -q "Out of memory" /var/log/syslog; then /usr/local/emhttp/plugins/dynamix/scripts/notify -e "OOM Checker" -s "Checked for OOM in syslog" -d "OOM error found in syslog" -i "alert" fi

Oom is not really an issue any more, sure that you need this?

Yes it did ! Verzonden vanaf mijn iPhone met Tapatalk

Seems that did it... It is stable now..

And again... Changed it to 16384M now.. ERROR: CrashPlan for Small Business is running out of memory. The application crashed because of lack of memory. More memory needs to be allocated. This can be done via the CRASHPLAN_SRV_MAX_MEM environment variable.

Now it does not continue starting but the error is back.. I will enlarge the memory to 8192M [app] starting CrashPlan for Small Business...ERROR: CrashPlan for Small Business is running out of memory. The application crashed because of lack of memory. More memory needs to be allocated. This can be done via the CRASHPLAN_SRV_MAX_MEM environment variable.

The whole log is filled with: Crashplan engine - starting

The GUI cannot connect to its background process.. (crashplan notification, not the docker vnc..)

It is running but I see an error message now.. Maybe that was causing issues before also: Application crashed because of lack of memory, incrrease crashplan_srv_max_mem. How do I go about that ?

I installed a docker update yesterday, and after that it changed to a complete black screen... I just saw there was another now and am installing that.. If there still are issues I will post a screenshot !

That does not help, tried several times allready Verzonden vanaf mijn iPhone met Tapatalk

For what it is worth: My crashplan docker is refusing to show the gui since somewhere today... Nothing has changed as far as I can recall.. I only get the top menu bar (File Edit View Tools, etc), and the bar does not respond when clicked on... Was functioning this morning..

Those rights look fine. The plex docker by plex inc. works fine. I have switched to that. The plex version on linux.io is newer then the one in the "official docker" so the issue could still lie within plex though. There are plex threads on the issue and several point to start using the offical plex docker instead of a third party one..

Anyone ?

I have found sopme threads pointing to an issue indeed with the created docker image.. Can it be that the file paths are mounted with the NOEXEC option on ? This will make sure no binaries can be run..

I notice some video files refuse to play .. Some however work fine..: ov 12, 2017 13:31:19.002 [0x14b843dfe700] ERROR - [Transcoder] Error while decoding stream #0:1: Input/output error Nov 12, 2017 13:31:22.000 [0x14b837bf5700] ERROR - [Transcoder] [eac3_eae @ 0x1532240] EAE timeout! EAE not running, or wrong folder? Could not read '/tmp/pms-f1acd851-c063-4a52-bad4-e4467c7d7467/EasyAudioEncoder/Convert to WAV (to 8ch or less)/hgpmn5o0ll4iqxjelwhg0ik8_6351-1-67.wav' Nov 12, 2017 13:31:22.001 [0x14b843dfe700] ERROR - [Transcoder] [eac3_eae @ 0x1532240] error reading output Nov 12, 2017 13:31:22.002 [0x14b837bf5700] ERROR - [Transcoder] Error while decoding stream #0:1: Input/output error Nov 12, 2017 13:31:25.001 [0x14b837bf5700] ERROR - [Transcoder] [eac3_eae @ 0x1532240] EAE timeout! EAE not running, or wrong folder? Could not read '/tmp/pms-f1acd851-c063-4a52-bad4-e4467c7d7467/EasyAudioEncoder/Convert to WAV (to 8ch or less)/hgpmn5o0ll4iqxjelwhg0ik8_6351-1-68.wav' Nov 12, 2017 13:31:25.002 [0x14b843dfe700] ERROR - [Transcoder] [eac3_eae @ 0x1532240] error reading output Nov 12, 2017 13:31:25.002 [0x14b837bf5700] ERROR - [Transcoder] Error while decoding stream #0:1: Input/output error Nov 12, 2017 13:31:25.209 [0x14b841bfb700] WARN - Transcode runner appears to have died. Nov 12, 2017 13:31:25.220 [0x14b8421fe700] WARN - Transcode runner appears to have died. Anyone ? I think the issue is here: JobManager: child process returned: 13 (Permission denied) JobManager: child process returned: 13 (Permission denied) Can it be that the file paths are mounted with the NOEXEC option on ? This will make sure no binaries can be run..

I read that and my gui is not left open..

I am having an issue with Syncthing.. It synced over 70% of my primary server to my secundairy (which is standing next to it). I am just trying in here if someone can help, if not, I will write a mail on the product home page of syncthing. The syncthing logfile of my primary server: [s6-init] making user provided files available at /var/run/s6/etc...exited 0. [s6-init] ensuring user provided files have correct perms...exited 0. [fix-attrs.d] applying ownership & permissions fixes... [fix-attrs.d] done. [cont-init.d] executing container initialization scripts... [cont-init.d] 10-adduser: executing... ------------------------------------- _ _ _ | |___| (_) ___ | / __| | |/ _ \ | \__ \ | | (_) | |_|___/ |_|\___/ |_| Brought to you by linuxserver.io We gratefully accept donations at: https://www.linuxserver.io/donations/ ------------------------------------- GID/UID ------------------------------------- User uid: 99 User gid: 100 ------------------------------------- [cont-init.d] 10-adduser: exited 0. [cont-init.d] done. [services.d] starting services [services.d] done. [NYD47] 01:07:16 INFO: syncthing v0.14.39 "Dysprosium Dragonfly" (go1.8.4 linux-amd64) root@4430ab19aba5 2017-10-27 22:54:14 UTC [noupgrade] [NYD47] 01:07:16 INFO: My ID: NYD476I-JIDSNKM-GBFSVHP-F6SBLHR-XVQZM7N-F6IQYAK-TCXMNSC-P2N3IAJ [NYD47] 01:07:17 INFO: Single thread SHA256 performance is 197 MB/s using minio/sha256-simd (135 MB/s using crypto/sha256). [NYD47] 01:07:17 INFO: Hashing performance with weak hash is 165.96 MB/s [NYD47] 01:07:18 INFO: Hashing performance without weak hash is 202.78 MB/s [NYD47] 01:07:18 INFO: Weak hash enabled, as it has an acceptable performance impact. [NYD47] 01:07:28 INFO: Ready to synchronize "Default Folder" (default) (readwrite) [NYD47] 01:14:20 INFO: Ready to synchronize "Tower-data" (rtecd-abbex) (readonly) [NYD47] 01:14:20 INFO: Send rate is unlimited, receive rate is unlimited [NYD47] 01:14:20 INFO: Rate limits do not apply to LAN connections [NYD47] 01:14:20 INFO: TCP listener ([::]:22000) starting [NYD47] 01:14:20 INFO: Completed initial scan of readwrite folder "Default Folder" (default) [NYD47] 01:14:20 INFO: Device NYD476I-JIDSNKM-GBFSVHP-F6SBLHR-XVQZM7N-F6IQYAK-TCXMNSC-P2N3IAJ is "Tower" at [dynamic] [NYD47] 01:14:20 INFO: Device 7CCSKMK-DCMAXVG-2XBD7HK-22XF4MR-2WKU36O-DJ3QZ52-CW5JEZV-JJHMKAN is "Vault" at [tcp://192.168.1.41:22000] [NYD47] 01:14:20 INFO: Starting usage reporting [NYD47] 01:14:20 INFO: GUI and API listening on [::]:8384 [NYD47] 01:14:20 INFO: Access the GUI via the following URL: http://127.0.0.1:8384/ [NYD47] 01:14:20 INFO: Established secure connection to 7CCSKMK-DCMAXVG-2XBD7HK-22XF4MR-2WKU36O-DJ3QZ52-CW5JEZV-JJHMKAN at 192.168.1.40:60238-192.168.1.41:22000 (tcp-client) (TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305) [NYD47] 01:14:20 INFO: Device 7CCSKMK-DCMAXVG-2XBD7HK-22XF4MR-2WKU36O-DJ3QZ52-CW5JEZV-JJHMKAN client is "syncthing v0.14.39" named "Vault" [NYD47] 02:00:02 INFO: Connection to 7CCSKMK-DCMAXVG-2XBD7HK-22XF4MR-2WKU36O-DJ3QZ52-CW5JEZV-JJHMKAN closed: reading length: read tcp 192.168.1.40:60238->192.168.1.41:22000: read: connection reset by peer [NYD47] 02:03:48 INFO: Completed initial scan of readonly folder "Tower-data" (rtecd-abbex) [NYD47] 02:07:58 INFO: Established secure connection to 7CCSKMK-DCMAXVG-2XBD7HK-22XF4MR-2WKU36O-DJ3QZ52-CW5JEZV-JJHMKAN at 192.168.1.40:22000-192.168.1.41:53994 (tcp-server) (TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305) [NYD47] 02:07:58 INFO: Device 7CCSKMK-DCMAXVG-2XBD7HK-22XF4MR-2WKU36O-DJ3QZ52-CW5JEZV-JJHMKAN client is "syncthing v0.14.39" named "Vault" [NYD47] 06:42:07 INFO: Connection to 7CCSKMK-DCMAXVG-2XBD7HK-22XF4MR-2WKU36O-DJ3QZ52-CW5JEZV-JJHMKAN closed: reading length: read tcp 192.168.1.40:22000->192.168.1.41:53994: read: connection reset by peer [NYD47] 06:53:34 INFO: Established secure connection to 7CCSKMK-DCMAXVG-2XBD7HK-22XF4MR-2WKU36O-DJ3QZ52-CW5JEZV-JJHMKAN at 192.168.1.40:22000-192.168.1.41:59340 (tcp-server) (TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305) [NYD47] 06:53:34 INFO: Device 7CCSKMK-DCMAXVG-2XBD7HK-22XF4MR-2WKU36O-DJ3QZ52-CW5JEZV-JJHMKAN client is "syncthing v0.14.39" named "Vault" The syncthing logfile of my secundary unraid server: ------------------------------------- _ _ _ | |___| (_) ___ | / __| | |/ _ \ | \__ \ | | (_) | |_|___/ |_|\___/ |_| Brought to you by linuxserver.io We gratefully accept donations at: https://www.linuxserver.io/donations/ ------------------------------------- GID/UID ------------------------------------- User uid: 99 User gid: 100 ------------------------------------- [cont-init.d] 10-adduser: exited 0. [cont-init.d] done. [services.d] starting services [services.d] done. [7CCSK] 06:44:35 INFO: syncthing v0.14.39 "Dysprosium Dragonfly" (go1.8.4 linux-amd64) root@4430ab19aba5 2017-10-27 22:54:14 UTC [noupgrade] [7CCSK] 06:44:35 INFO: My ID: 7CCSKMK-DCMAXVG-2XBD7HK-22XF4MR-2WKU36O-DJ3QZ52-CW5JEZV-JJHMKAN [7CCSK] 06:44:36 INFO: Single thread SHA256 performance is 305 MB/s using minio/sha256-simd (203 MB/s using crypto/sha256). [7CCSK] 06:44:36 INFO: Hashing performance with weak hash is 261.76 MB/s [7CCSK] 06:44:37 INFO: Hashing performance without weak hash is 299.25 MB/s [7CCSK] 06:44:37 INFO: Weak hash enabled, as it has an acceptable performance impact. [7CCSK] 06:44:43 INFO: Ready to synchronize "Default Folder" (default) (readwrite) [7CCSK] 06:53:34 INFO: Ready to synchronize "Tower-data" (rtecd-abbex) (readwrite) [7CCSK] 06:53:34 INFO: Send rate is unlimited, receive rate is unlimited [7CCSK] 06:53:34 INFO: Rate limits do not apply to LAN connections [7CCSK] 06:53:34 INFO: TCP listener ([::]:22000) starting [7CCSK] 06:53:34 INFO: Completed initial scan of readwrite folder "Default Folder" (default) [7CCSK] 06:53:34 INFO: Device 7CCSKMK-DCMAXVG-2XBD7HK-22XF4MR-2WKU36O-DJ3QZ52-CW5JEZV-JJHMKAN is "Vault" at [dynamic] [7CCSK] 06:53:34 INFO: Device NYD476I-JIDSNKM-GBFSVHP-F6SBLHR-XVQZM7N-F6IQYAK-TCXMNSC-P2N3IAJ is "Tower" at [tcp://192.168.1.40:22000] [7CCSK] 06:53:34 INFO: Starting usage reporting [7CCSK] 06:53:34 INFO: GUI and API listening on [::]:8384 [7CCSK] 06:53:34 INFO: Access the GUI via the following URL: http://127.0.0.1:8384/ [7CCSK] 06:53:34 INFO: Established secure connection to NYD476I-JIDSNKM-GBFSVHP-F6SBLHR-XVQZM7N-F6IQYAK-TCXMNSC-P2N3IAJ at 192.168.1.41:59340-192.168.1.40:22000 (tcp-client) (TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305) [7CCSK] 06:53:34 INFO: Device NYD476I-JIDSNKM-GBFSVHP-F6SBLHR-XVQZM7N-F6IQYAK-TCXMNSC-P2N3IAJ client is "syncthing v0.14.39" named "Tower" It basically looks like everything is working, no error messages, the server even says its at 70%.. But it remains at that for days and days... Restarting docker and/or server does not make a difference.. The database log is active though: 18:54:10.023626 table@compaction committed F-2 S-474B Ke·0 D·2 T·403.784714ms 18:54:10.023912 table@remove removed @5153375 18:54:10.025817 table@remove removed @5017880 18:54:10.026242 table@remove removed @4892481 18:54:10.026635 table@remove removed @4892482 18:54:10.027045 table@remove removed @4892483 18:54:10.027412 table@remove removed @4892484 18:54:10.027516 table@remove removed @4892485 18:54:10.028217 table@remove removed @4593788 18:54:10.028613 table@remove removed @4593789 18:54:10.029045 table@remove removed @4593790 18:54:10.029210 table@remove removed @4593791 18:55:50.598876 table@compaction L3·1 -> L4·5 S·8MiB Q·518126735 18:55:50.639635 table@build created L4@5154414 N·90 S·2MiB "\x00\x00\x00..nfo,v507287658":"\x00\x00\x00..mkv,v46958744" 18:55:50.692242 table@build created L4@5154415 N·48 S·2MiB "\x00\x00\x00..nfo,v46958732":"\x00\x00\x00..mkv,v46882739" 18:55:50.724982 table@build created L4@5154416 N·40 S·2MiB "\x00\x00\x00..nfo,v46882733":"\x00\x00\x00..mkv,v46829899" 18:55:50.800282 table@build created L4@5154417 N·98 S·2MiB "\x00\x00\x00..nfo,v46821656":"\x00\x00\x00..mkv,v180467045" 18:55:50.825914 version@stat F·[0 72 657 5913 15834] S·43GiB[0B 94MiB 995MiB 9GiB 33GiB] Sc·[0.00 0.95 1.00 1.00 0.34] 18:55:50.862967 table@compaction committed F-2 S-386B Ke·0 D·2 T·264.031158ms 18:55:50.863254 table@remove removed @5153379 18:55:50.865455 table@remove removed @5090947 18:55:50.865567 table@remove removed @5090948 18:55:50.865877 table@remove removed @5071123 18:55:50.866164 table@remove removed @5071124 18:55:50.866421 table@remove removed @5071125 18:59:12.842652 table@compaction L3·1 -> L4·2 S·3MiB Q·518126743 18:59:12.873480 table@build created L4@5154418 N·139 S·2MiB "\x00\x00\x00..srt,v172149271":"\x00\x00\x00..avi,v96227265" 18:59:12.921038 table@build created L4@5154419 N·169 S·1MiB "\x00\x00\x00..nfo,v96227241":"\x00\x00\x00..mkv,v141277036" 18:59:12.943405 version@stat F·[0 72 657 5912 15834] S·43GiB[0B 94MiB 995MiB 9GiB 33GiB] Sc·[0.00 0.95 1.00 1.00 0.34] 18:59:12.979282 table@compaction committed F-1 S-293B Ke·0 D·2 T·136.557864ms 18:59:12.979635 table@remove removed @5153393 18:59:12.981871 table@remove removed @4896378 18:59:12.982409 table@remove removed @994746 Anyone any idea what I could do ? Both servers only do a local connect, where I specify the ip address and port..