Jump to content

stridemat

Members
 View Profile  See their activity

  • Posts

    71

  • Joined

  • Last visited

 Content Type 

Posts posted by stridemat

    [Script] binhex - no_ransom.sh

    in User Customizations

    Posted · Edited by stridemat

    24 minutes ago, binhex said:

    hmm that should work, i will do some further testing, as a possible workaround you could remove the exclude and instead use the include to only lock file types you want to have locked e.g. for ebooks *.epub, *.mobi etc.

    Thanks. I shall do some further investigation as well over the next couple of days. 

    [Script] binhex - no_ransom.sh

    in User Customizations

    Posted · Edited by stridemat

    Thanks for this - a handy little script.

     

    Any reason why the below would not be excluding jpg, opf, db and json files from my Test share? 

      

    /mnt/user/appdata/no_ransom/no_ransom.sh --lock-files 'yes' --media-shares 'Test' --include-extensions '*.*' --exclude-extensions '*.jpg,*.opf,*.db,*.json' --debug 'yes'

    To explain the use case, I have the calibre library in my media > eBooks share which is a .db file. There are other files within this share that I also do not want to 'lock' so I had hoped to exclude them from the locking. However, when locking with the above, the files with the noted extension are also locked. 

     

    The Media>eBooks folder has been copied into my Test share.

    [Support] binhex - SABnzbdVPN

    in Docker Containers

    Posted

    On 7/19/2020 at 8:06 AM, stridemat said:

    Hi,

     

    I have my system set up to back up docker containers every Sunday morning. However, without fail I seem to get a ‘connection failed’ error within SABnzbdVPN upon the container restarting. Frustrating as none of the other containers that rely on the proxy will work either, until I go in and manually restart SABnzbdVPN.

     

    Any ideas what might be causing the connection failed? I have a working system otherwise. 

    E1F7A0BC-7F1B-47F6-969E-FF9E851118CC.jpeg

     

    I have added some logs which I think may show the issue:

      

    
2020-07-19 07:51:40,542 DEBG 'start-script' stdout output:
Sun Jul 19 07:51:40 2020 ROUTE6: default_gateway=UNDEF
Sun Jul 19 07:51:40 2020 OpenVPN ROUTE6: OpenVPN needs a gateway parameter for a --route-ipv6 option and no default was specified by either --route-ipv6-gateway or --ifconfig-ipv6 options
Sun Jul 19 07:51:40 2020 OpenVPN ROUTE: failed to parse/resolve route for host/network: fc00::/7

Sun Jul 19 07:51:40 2020 OpenVPN ROUTE6: OpenVPN needs a gateway parameter for a --route-ipv6 option and no default was specified by either --route-ipv6-gateway or --ifconfig-ipv6 options
Sun Jul 19 07:51:40 2020 OpenVPN ROUTE: failed to parse/resolve route for host/network: 3000::/4

Sun Jul 19 07:51:40 2020 OpenVPN ROUTE6: OpenVPN needs a gateway parameter for a --route-ipv6 option and no default was specified by either --route-ipv6-gateway or --ifconfig-ipv6 options
Sun Jul 19 07:51:40 2020 OpenVPN ROUTE: failed to parse/resolve route for host/network: 2000::/4

Sun Jul 19 07:51:40 2020 OpenVPN ROUTE6: OpenVPN needs a gateway parameter for a --route-ipv6 option and no default was specified by either --route-ipv6-gateway or --ifconfig-ipv6 options
Sun Jul 19 07:51:40 2020 OpenVPN ROUTE: failed to parse/resolve route for host/network: ::/3


2020-07-19 07:51:40,542 DEBG 'start-script' stdout output:
Sun Jul 19 07:51:40 2020 TUN/TAP device tun0 opened
Sun Jul 19 07:51:40 2020 TUN/TAP TX queue length set to 100
Sun Jul 19 07:51:40 2020 /usr/bin/ip link set dev tun0 up mtu 1500

2020-07-19 07:51:40,543 DEBG 'start-script' stdout output:
Sun Jul 19 07:51:40 2020 /usr/bin/ip addr add dev tun0 10.32.208.193/24 broadcast 10.32.208.255

2020-07-19 07:51:40,544 DEBG 'start-script' stdout output:
Sun Jul 19 07:51:40 2020 /root/openvpnup.sh tun0 1500 1553 10.32.208.193 255.255.255.0 init

2020-07-19 07:51:40,660 DEBG 'start-script' stdout output:
[info] Application does not require port forwarding or VPN provider is != pia, skipping incoming port assignment

2020-07-19 07:51:40,660 DEBG 'start-script' stdout output:
[info] Checking we can resolve name 'www.google.com' to address...

2020-07-19 07:51:40,663 DEBG 'start-script' stdout output:
[debug] Having issues resolving name 'www.google.com', sleeping before retry...

2020-07-19 07:51:45,599 DEBG 'start-script' stdout output:
Sun Jul 19 07:51:45 2020 /usr/bin/ip route add 134.19.179.242/32 via 172.17.0.1

2020-07-19 07:51:45,600 DEBG 'start-script' stdout output:
Sun Jul 19 07:51:45 2020 /usr/bin/ip route add 0.0.0.0/1 via 10.32.208.1

2020-07-19 07:51:45,601 DEBG 'start-script' stdout output:
Sun Jul 19 07:51:45 2020 /usr/bin/ip route add 128.0.0.0/1 via 10.32.208.1

2020-07-19 07:51:45,602 DEBG 'start-script' stdout output:
Sun Jul 19 07:51:45 2020 WARNING: OpenVPN was configured to add an IPv6 route over tun0. However, no IPv6 has been configured for this interface, therefore the route installation may fail or may not work as expected.

     

     

    On 8/3/2020 at 6:53 AM, stridemat said:

    So this is still happening every Sunday morning and I’m at a loss as to why.  The setting within ‘CA Appdata Backup/Restore v2’ are as below. Looks ok to me and no other app has this issue. 


    A329CA92-AF65-4C72-A07E-B1FA31BC6F1C.thumb.jpeg.dcd953fe4a79569bc6a58599cea79525.jpeg

     So still having this issue and at a loss to why. Looking at the Unraid logs and not just the docker logs the following is noted:

     

    Quote

    Aug 16 07:16:10 Tower kernel: docker0: port 6(veth2477b33) entered disabled state
    Aug 16 07:16:10 Tower kernel: device veth2477b33 left promiscuous mode
    Aug 16 07:16:10 Tower kernel: docker0: port 6(veth2477b33) entered disabled state
    Aug 16 07:16:10 Tower avahi-daemon[5008]: Withdrawing address record for fe80::e09d:52ff:fe52:f7eb on veth2477b33.
    Aug 16 07:16:10 Tower kernel: docker0: port 6(vethd37a551) entered blocking state
    Aug 16 07:16:10 Tower kernel: docker0: port 6(vethd37a551) entered disabled state
    Aug 16 07:16:10 Tower kernel: device vethd37a551 entered promiscuous mode
    Aug 16 07:16:10 Tower kernel: IPv6: ADDRCONF(NETDEV_UP): vethd37a551: link is not ready
    Aug 16 07:16:10 Tower kernel: docker0: port 6(vethd37a551) entered blocking state
    Aug 16 07:16:10 Tower kernel: docker0: port 6(vethd37a551) entered forwarding state
    Aug 16 07:16:10 Tower kernel: eth0: renamed from veth23107a7
    Aug 16 07:16:10 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethd37a551: link becomes ready
    Aug 16 07:16:11 Tower avahi-daemon[5008]: Joining mDNS multicast group on interface vethd37a551.IPv6 with address fe80::e80b:bcff:fe53:3afa.
    Aug 16 07:16:11 Tower avahi-daemon[5008]: New relevant interface vethd37a551.IPv6 for mDNS.
    Aug 16 07:16:11 Tower avahi-daemon[5008]: Registering new address record for fe80::e80b:bcff:fe53:3afa on vethd37a551.*.

     That’s the output when restarting the docker container manually having had the connection failed issue. I do not have IPv6 set up in the docker. Would this be cashing my issue?

    [Support] binhex - SABnzbdVPN

    in Docker Containers

    Posted · Edited by stridemat

    On 7/19/2020 at 8:06 AM, stridemat said:

    Hi,

     

    I have my system set up to back up docker containers every Sunday morning. However, without fail I seem to get a ‘connection failed’ error within SABnzbdVPN upon the container restarting. Frustrating as none of the other containers that rely on the proxy will work either, until I go in and manually restart SABnzbdVPN.

     

    Any ideas what might be causing the connection failed? I have a working system otherwise. 

    E1F7A0BC-7F1B-47F6-969E-FF9E851118CC.jpeg

     

    I have added some logs which I think may show the issue:

      

    
2020-07-19 07:51:40,542 DEBG 'start-script' stdout output:
Sun Jul 19 07:51:40 2020 ROUTE6: default_gateway=UNDEF
Sun Jul 19 07:51:40 2020 OpenVPN ROUTE6: OpenVPN needs a gateway parameter for a --route-ipv6 option and no default was specified by either --route-ipv6-gateway or --ifconfig-ipv6 options
Sun Jul 19 07:51:40 2020 OpenVPN ROUTE: failed to parse/resolve route for host/network: fc00::/7

Sun Jul 19 07:51:40 2020 OpenVPN ROUTE6: OpenVPN needs a gateway parameter for a --route-ipv6 option and no default was specified by either --route-ipv6-gateway or --ifconfig-ipv6 options
Sun Jul 19 07:51:40 2020 OpenVPN ROUTE: failed to parse/resolve route for host/network: 3000::/4

Sun Jul 19 07:51:40 2020 OpenVPN ROUTE6: OpenVPN needs a gateway parameter for a --route-ipv6 option and no default was specified by either --route-ipv6-gateway or --ifconfig-ipv6 options
Sun Jul 19 07:51:40 2020 OpenVPN ROUTE: failed to parse/resolve route for host/network: 2000::/4

Sun Jul 19 07:51:40 2020 OpenVPN ROUTE6: OpenVPN needs a gateway parameter for a --route-ipv6 option and no default was specified by either --route-ipv6-gateway or --ifconfig-ipv6 options
Sun Jul 19 07:51:40 2020 OpenVPN ROUTE: failed to parse/resolve route for host/network: ::/3


2020-07-19 07:51:40,542 DEBG 'start-script' stdout output:
Sun Jul 19 07:51:40 2020 TUN/TAP device tun0 opened
Sun Jul 19 07:51:40 2020 TUN/TAP TX queue length set to 100
Sun Jul 19 07:51:40 2020 /usr/bin/ip link set dev tun0 up mtu 1500

2020-07-19 07:51:40,543 DEBG 'start-script' stdout output:
Sun Jul 19 07:51:40 2020 /usr/bin/ip addr add dev tun0 10.32.208.193/24 broadcast 10.32.208.255

2020-07-19 07:51:40,544 DEBG 'start-script' stdout output:
Sun Jul 19 07:51:40 2020 /root/openvpnup.sh tun0 1500 1553 10.32.208.193 255.255.255.0 init

2020-07-19 07:51:40,660 DEBG 'start-script' stdout output:
[info] Application does not require port forwarding or VPN provider is != pia, skipping incoming port assignment

2020-07-19 07:51:40,660 DEBG 'start-script' stdout output:
[info] Checking we can resolve name 'www.google.com' to address...

2020-07-19 07:51:40,663 DEBG 'start-script' stdout output:
[debug] Having issues resolving name 'www.google.com', sleeping before retry...

2020-07-19 07:51:45,599 DEBG 'start-script' stdout output:
Sun Jul 19 07:51:45 2020 /usr/bin/ip route add 134.19.179.242/32 via 172.17.0.1

2020-07-19 07:51:45,600 DEBG 'start-script' stdout output:
Sun Jul 19 07:51:45 2020 /usr/bin/ip route add 0.0.0.0/1 via 10.32.208.1

2020-07-19 07:51:45,601 DEBG 'start-script' stdout output:
Sun Jul 19 07:51:45 2020 /usr/bin/ip route add 128.0.0.0/1 via 10.32.208.1

2020-07-19 07:51:45,602 DEBG 'start-script' stdout output:
Sun Jul 19 07:51:45 2020 WARNING: OpenVPN was configured to add an IPv6 route over tun0. However, no IPv6 has been configured for this interface, therefore the route installation may fail or may not work as expected.

     

    So this is still happening every Sunday morning and I’m at a loss as to why.  The setting within ‘CA Appdata Backup/Restore v2’ are as below. Looks ok to me and no other app has this issue. 


    A329CA92-AF65-4C72-A07E-B1FA31BC6F1C.thumb.jpeg.dcd953fe4a79569bc6a58599cea79525.jpeg

    [Support] binhex - SABnzbdVPN

    in Docker Containers

    Posted

    1 minute ago, binhex said:

    CA Auto Update is not used for backups,  that is used to auto update apps, the backup plugin is called 'CA Appdata Backup/Restore v2', check the settings.

    Yeah. Wrong plugin. I will take a look at the settings when I finish work. 

    [Support] binhex - SABnzbdVPN

    in Docker Containers

    Posted

    5 hours ago, binhex said:

    that depends on how you have it set, i believe there is an option to 'pause' containers during backup, you must NOT use this option with any of my vpn docker images as they will not play nicely with pause/resume, you have to perform a shutdown of the container, backup, then a startup.

    Thanks for the quick response - I shall take a look though I do think CA Auto Update Applications does shutdown, instead of pausing.

    [Support] binhex - SABnzbdVPN

    in Docker Containers

    Posted · Edited by stridemat
    Added logs

    Hi,

     

    I have my system set up to back up docker containers every Sunday morning. However, without fail I seem to get a ‘connection failed’ error within SABnzbdVPN upon the container restarting. Frustrating as none of the other containers that rely on the proxy will work either, until I go in and manually restart SABnzbdVPN.

     

    Any ideas what might be causing the connection failed? I have a working system otherwise. 

    E1F7A0BC-7F1B-47F6-969E-FF9E851118CC.jpeg

     

    I have added some logs which I think may show the issue:

      

    2020-07-19 07:51:40,542 DEBG 'start-script' stdout output:
Sun Jul 19 07:51:40 2020 ROUTE6: default_gateway=UNDEF
Sun Jul 19 07:51:40 2020 OpenVPN ROUTE6: OpenVPN needs a gateway parameter for a --route-ipv6 option and no default was specified by either --route-ipv6-gateway or --ifconfig-ipv6 options
Sun Jul 19 07:51:40 2020 OpenVPN ROUTE: failed to parse/resolve route for host/network: fc00::/7

Sun Jul 19 07:51:40 2020 OpenVPN ROUTE6: OpenVPN needs a gateway parameter for a --route-ipv6 option and no default was specified by either --route-ipv6-gateway or --ifconfig-ipv6 options
Sun Jul 19 07:51:40 2020 OpenVPN ROUTE: failed to parse/resolve route for host/network: 3000::/4

Sun Jul 19 07:51:40 2020 OpenVPN ROUTE6: OpenVPN needs a gateway parameter for a --route-ipv6 option and no default was specified by either --route-ipv6-gateway or --ifconfig-ipv6 options
Sun Jul 19 07:51:40 2020 OpenVPN ROUTE: failed to parse/resolve route for host/network: 2000::/4

Sun Jul 19 07:51:40 2020 OpenVPN ROUTE6: OpenVPN needs a gateway parameter for a --route-ipv6 option and no default was specified by either --route-ipv6-gateway or --ifconfig-ipv6 options
Sun Jul 19 07:51:40 2020 OpenVPN ROUTE: failed to parse/resolve route for host/network: ::/3


2020-07-19 07:51:40,542 DEBG 'start-script' stdout output:
Sun Jul 19 07:51:40 2020 TUN/TAP device tun0 opened
Sun Jul 19 07:51:40 2020 TUN/TAP TX queue length set to 100
Sun Jul 19 07:51:40 2020 /usr/bin/ip link set dev tun0 up mtu 1500

2020-07-19 07:51:40,543 DEBG 'start-script' stdout output:
Sun Jul 19 07:51:40 2020 /usr/bin/ip addr add dev tun0 10.32.208.193/24 broadcast 10.32.208.255

2020-07-19 07:51:40,544 DEBG 'start-script' stdout output:
Sun Jul 19 07:51:40 2020 /root/openvpnup.sh tun0 1500 1553 10.32.208.193 255.255.255.0 init

2020-07-19 07:51:40,660 DEBG 'start-script' stdout output:
[info] Application does not require port forwarding or VPN provider is != pia, skipping incoming port assignment

2020-07-19 07:51:40,660 DEBG 'start-script' stdout output:
[info] Checking we can resolve name 'www.google.com' to address...

2020-07-19 07:51:40,663 DEBG 'start-script' stdout output:
[debug] Having issues resolving name 'www.google.com', sleeping before retry...

2020-07-19 07:51:45,599 DEBG 'start-script' stdout output:
Sun Jul 19 07:51:45 2020 /usr/bin/ip route add 134.19.179.242/32 via 172.17.0.1

2020-07-19 07:51:45,600 DEBG 'start-script' stdout output:
Sun Jul 19 07:51:45 2020 /usr/bin/ip route add 0.0.0.0/1 via 10.32.208.1

2020-07-19 07:51:45,601 DEBG 'start-script' stdout output:
Sun Jul 19 07:51:45 2020 /usr/bin/ip route add 128.0.0.0/1 via 10.32.208.1

2020-07-19 07:51:45,602 DEBG 'start-script' stdout output:
Sun Jul 19 07:51:45 2020 WARNING: OpenVPN was configured to add an IPv6 route over tun0. However, no IPv6 has been configured for this interface, therefore the route installation may fail or may not work as expected.

     

    [Plugin] Linuxserver.io - Unraid Nvidia

    in Plugin Support

    Posted

    5 hours ago, snoopsau said:

    NVIDIA-SMI 450.57       Driver Version: 450.57       CUDA Version: 11.0

     

    No idea if it fixes the P-States in Plex - but thats the version currently in 6.9 beta24

     

    Edit:

    It does work for some AI stuff I am playing with though -->

     

    Every 1.0s: nvidia-smi                                                                                                                                                                                                                                                                                gputest: Sat Jul 11 23:50:18 2020

    Sat Jul 11 23:50:18 2020
    +-----------------------------------------------------------------------------+
    | NVIDIA-SMI 450.57       Driver Version: 450.57       CUDA Version: 11.0     |
    |-------------------------------+----------------------+----------------------+
    | GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
    | Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
    |                               |                      |               MIG M. |
    |===============================+======================+======================|
    |   0  Quadro P400         Off  | 00000000:0B:00.0 Off |                  N/A |
    | 34%   32C    P8    N/A /  N/A |    771MiB /  2000MiB |      0%      Default |
    |                               |                      |                  N/A |
    +-------------------------------+----------------------+----------------------+

    +-----------------------------------------------------------------------------+
    | Processes:                                                                  |
    |  GPU   GI   CI        PID   Type   Process name                  GPU Memory |
    |        ID   ID                                                   Usage      |
    |=============================================================================|
    |    0   N/A  N/A      7163      C   python3                           769MiB |
    +-----------------------------------------------------------------------------+

    450.x seems like the version that fixes the bug. Thanks. 

    On VM start server partially crashes

    in VM Engine (KVM)

    Posted

    See logs below. 

    When starting a Windows 10 VM with dedicated GPU (Nvidia 1050ti) the system seems to partly crash. It still works, but the VM’s tab won’t open. I have another GPU passed though for other server duties. After a restart it seems to all work again, but this is the second time it has happened so there is obviously something not quite right.

     

    Anyone any ideas? 

      

    Jul 1 19:56:22 Tower kernel: NVRM: Attempting to remove minor device 1 with non-zero usage count!
Jul 1 19:56:22 Tower kernel: ------------[ cut here ]------------
Jul 1 19:56:22 Tower kernel: WARNING: CPU: 13 PID: 6559 at /tmp/SBo/NVIDIA-Linux-x86_64-440.59/kernel/nvidia/nv-pci.c:577 nv_pci_remove+0xe9/0x2fc [nvidia]
Jul 1 19:56:22 Tower kernel: Modules linked in: sr_mod cdrom nvidia_uvm(O) xt_CHECKSUM ipt_REJECT ip6table_mangle ip6table_nat nf_nat_ipv6 iptable_mangle ip6table_filter ip6_tables xt_nat vhost_net tun vhost tap veth iptable_filter xfs md_mod i915 video backlight iosf_mbi intel_gtt i2c_algo_bit iptable_nat ipt_MASQUERADE nf_nat_ipv4 nf_nat ip_tables wireguard ip6_udp_tunnel udp_tunnel bonding nvidia_drm(PO) nvidia_modeset(PO) nvidia(PO) drm_kms_helper edac_mce_amd crc32_pclmul pcbc aesni_intel aes_x86_64 glue_helper crypto_simd ghash_clmulni_intel cryptd drm kvm_amd kvm r8169 syscopyarea sysfillrect sysimgblt fb_sys_fops realtek agpgart i2c_piix4 i2c_core wmi_bmof ahci ccp libahci crct10dif_pclmul crc32c_intel pcc_cpufreq wmi button acpi_cpufreq
Jul 1 19:56:22 Tower kernel: CPU: 13 PID: 6559 Comm: libvirtd Tainted: P O 4.19.107-Unraid #1
Jul 1 19:56:22 Tower kernel: Hardware name: Gigabyte Technology Co., Ltd. B450 AORUS M/B450 AORUS M, BIOS F50 11/27/2019
Jul 1 19:56:22 Tower kernel: RIP: 0010:nv_pci_remove+0xe9/0x2fc [nvidia]
Jul 1 19:56:22 Tower kernel: Code: aa 01 00 00 00 75 2c 8b 95 70 04 00 00 48 c7 c6 7b 35 98 a1 bf 04 00 00 00 e8 bd 7d 00 00 48 c7 c7 c2 35 98 a1 e8 31 a6 83 e0 <0f> 0b e8 c2 82 00 00 eb f9 4c 8d b5 50 04 00 00 4c 89 f7 e8 f7 42
Jul 1 19:56:22 Tower kernel: RSP: 0018:ffffc9000982bd50 EFLAGS: 00010246
Jul 1 19:56:22 Tower kernel: RAX: 0000000000000024 RBX: ffff888819a750a8 RCX: 0000000000000007
Jul 1 19:56:22 Tower kernel: RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88881e9564f0
Jul 1 19:56:22 Tower kernel: RBP: ffff8888163a7000 R08: 0000000000000003 R09: 000000000001d500
Jul 1 19:56:22 Tower kernel: R10: 0000000000000000 R11: 0000000000000044 R12: ffff8882543c3008
Jul 1 19:56:22 Tower kernel: R13: ffff888819a75000 R14: 0000000000000060 R15: ffff888721433cc0
Jul 1 19:56:22 Tower kernel: FS: 00001517828e4700(0000) GS:ffff88881e940000(0000) knlGS:0000000000000000
Jul 1 19:56:22 Tower kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jul 1 19:56:22 Tower kernel: CR2: 00001517828e0378 CR3: 00000007c3fe6000 CR4: 0000000000340ee0
Jul 1 19:56:22 Tower kernel: Call Trace:
Jul 1 19:56:22 Tower kernel: pci_device_remove+0x36/0x8e
Jul 1 19:56:22 Tower kernel: device_release_driver_internal+0x144/0x225
Jul 1 19:56:22 Tower kernel: unbind_store+0x6b/0xae
Jul 1 19:56:22 Tower kernel: kernfs_fop_write+0xf3/0x135
Jul 1 19:56:22 Tower kernel: __vfs_write+0x32/0x13a
Jul 1 19:56:22 Tower kernel: vfs_write+0xc7/0x166
Jul 1 19:56:22 Tower kernel: ksys_write+0x60/0xb2
Jul 1 19:56:22 Tower kernel: do_syscall_64+0x57/0xf2
Jul 1 19:56:22 Tower kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9
Jul 1 19:56:22 Tower kernel: RIP: 0033:0x15178438348f
Jul 1 19:56:22 Tower kernel: Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 49 fd ff ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 2d 44 89 c7 48 89 44 24 08 e8 7c fd ff ff 48
Jul 1 19:56:22 Tower kernel: RSP: 002b:00001517828e3530 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
Jul 1 19:56:22 Tower kernel: RAX: ffffffffffffffda RBX: 000000000000000c RCX: 000015178438348f
Jul 1 19:56:22 Tower kernel: RDX: 000000000000000c RSI: 000015177c05f7e0 RDI: 000000000000001e
Jul 1 19:56:22 Tower kernel: RBP: 000015177c05f7e0 R08: 0000000000000000 R09: 0000000000000000
Jul 1 19:56:22 Tower kernel: R10: 0000000000000000 R11: 0000000000000293 R12: 000000000000001e
Jul 1 19:56:22 Tower kernel: R13: 000000000000001e R14: 0000000000000000 R15: 000015177c05ee70
Jul 1 19:56:22 Tower kernel: ---[ end trace e1e51175159f6869 ]---
Jul 1 20:01:20 Tower nginx: 2020/07/01 20:01:20 [error] 7772#7772: *165929 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.100.25, server: , request: "POST /webGui/include/DashboardApps.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock", host: "192.168.100.100", referrer: "http://192.168.100.100/Dashboard"
Jul 1 20:02:35 Tower webGUI: Successful login user root from 192.168.100.25

     

×
×
  • Create New...