pmcnano

Members
  • Posts

    25
  • Joined

  • Last visited

Everything posted by pmcnano

  1. I was just looking for something like this. Thanks! That being said, your unraid template is missing somethings...I will try to fix it and submit a PR to your repo. Edit: It's actually all okay, the thing is, and I'm not sure how to fix, since the ports are not specified, the docker app doesn't offer to open the web gui. But just going to the port 8090 works fine. Probably worth allowing the user to specify which port is going to use. And I thiiink maybe the app icon has to be PNG but not entirely sure. Edit2: Seems like the database is reset after restarting the container? I assume is because it's not being stored in the appdata. Edit3: Sorry for all the edits. Added a path mapping, /app/pb_data to my appdata folder and the database is now persisted.
  2. Submitted a PR to fix your Muse template. Though even if it now runs, it still doesn't work while trying to play some media.
  3. Just as an FYI, this image gave me the answer: I don't recall ever moving my docker "Host access to custom networks" setting, but it's enabled. I have a feeling it was auto-enabled at some point by an update or something else. And per that table, it won't work with NAT = true. Since I didn't want to stop all my docker containers, I went with the last option, and added my static routes with NAT= false and my problems were solved.
  4. @CorneliousJD any reason to require a redis password? What if my redis instance has no password? 🤔
  5. @ich777idk if you noticed, nor if it's normal. But the Craftopia docker seems to be using a lot of CPU all the time? Even with no activity?
  6. balls, thanks! edit: pff, a vm won't do either, it requires a GPU for some reason.
  7. Hey! Do you mind making a craftopia server? 🥺 Thanks for your work!
  8. Hey @ich777 thanks for your apps! I tried looking for any repo I could just push a fix for this but couldn't find it. Either way, your mindustry "app" says the following: CONSOLE: To connect to the console open up the terminal for this docker and type in: 'docker exec -u terraria -ti NAMEOFYOURCONTAINER screen -xS Mindustry' (without quotes). The user is "mindustry" actually.
  9. Ah, thanks! You are right. Tho, the last post does mention it works fine with sqlite, which is what we are using, no? Edit: Tried with postgres and same thing, also commented on that post. I also found a post saying it might be permission issues with the data directory, but they seem to be root already. I will keep an eye on that issue. Thanks!
  10. @FoxxMD noticed that every time the docker restarts, it restarts the setup. You just complete it and your data is still there, but if I don't go there, the app doesn't run. For instance, if I restart my server, the slack notifications are down until I complete the setup again.
  11. Yup, it does suck a bit, something changed and my database got corrupted with the update a week ago, I Spent days trying to fix it and reinstalling didn't work either. Ended up doing above. I feel like @SpaceInvaderOne missed something in the update but I don't think he has connected in a while. We'll see, I had to setup my cameras again but I have it all working again.
  12. Since the update last night I am getting an error, I tried what @SpaceInvaderOne suggested for another problem a couple of replies before, but it didn't work. I removed the template and reinstalled, same error. 2020-05-14 17:06:31 11 [ERROR] mysqld: Incorrect information in file: './ccio/Presets.frm' Error: ER_NOT_FORM_FILE: Incorrect information in file: './ccio/Presets.frm' at Query.Sequence._packetToError (/opt/shinobi/node_modules/mysql/lib/protocol/sequences/Sequence.js:47:14) at Query.ErrorPacket (/opt/shinobi/node_modules/mysql/lib/protocol/sequences/Query.js:79:18) at Protocol._parsePacket (/opt/shinobi/node_modules/mysql/lib/protocol/Protocol.js:291:23) at Parser._parsePacket (/opt/shinobi/node_modules/mysql/lib/protocol/Parser.js:433:10) at Parser.write (/opt/shinobi/node_modules/mysql/lib/protocol/Parser.js:43:10) at Protocol.write (/opt/shinobi/node_modules/mysql/lib/protocol/Protocol.js:38:16) at Socket.<anonymous> (/opt/shinobi/node_modules/mysql/lib/Connection.js:88:28) at Socket.<anonymous> (/opt/shinobi/node_modules/mysql/lib/Connection.js:526:10) at Socket.emit (events.js:223:5) at addChunk (_stream_readable.js:309:12) at readableAddChunk (_stream_readable.js:290:11) at Socket.Readable.push (_stream_readable.js:224:10) at TCP.onStreamRead (internal/stream_base_commons.js:181:23) -------------------- at Protocol._enqueue (/opt/shinobi/node_modules/mysql/lib/protocol/Protocol.js:144:48) at Connection.query (/opt/shinobi/node_modules/mysql/lib/Connection.js:198:25) at /opt/shinobi/node_modules/knex/lib/dialects/mysql/index.js:130:18 at Promise._execute (/opt/shinobi/node_modules/bluebird/js/release/debuggability.js:384:9) at Promise._resolveFromExecutor (/opt/shinobi/node_modules/bluebird/js/release/promise.js:518:18) at new Promise (/opt/shinobi/node_modules/bluebird/js/release/promise.js:103:10) at Client_MySQL._query (/opt/shinobi/node_modules/knex/lib/dialects/mysql/index.js:124:12) at Client_MySQL.query (/opt/shinobi/node_modules/knex/lib/client.js:158:17) at Runner.query (/opt/shinobi/node_modules/knex/lib/runner.js:135:36) at /opt/shinobi/node_modules/knex/lib/runner.js:39:23 at tryCatcher (/opt/shinobi/node_modules/bluebird/js/release/util.js:16:23) at /opt/shinobi/node_modules/bluebird/js/release/using.js:185:26 at tryCatcher (/opt/shinobi/node_modules/bluebird/js/release/util.js:16:23) at Promise._settlePromiseFromHandler (/opt/shinobi/node_modules/bluebird/js/release/promise.js:547:31) at Promise._settlePromise (/opt/shinobi/node_modules/bluebird/js/release/promise.js:604:18) at Promise._settlePromise0 (/opt/shinobi/node_modules/bluebird/js/release/promise.js:649:10) { code: 'ER_NOT_FORM_FILE', errno: 1033, sqlMessage: "Incorrect information in file: './ccio/Presets.frm'", sqlState: 'HY000', index: 0, sql: 'ALTER TABLE `Presets` CHANGE COLUMN `type` `type` VARCHAR(50) NULL DEFAULT NULL AFTER `details`;' } !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! This Install of Shinobi is NOT Activated !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 2020-05-14T17:06:33-05:00 This Install of Shinobi is NOT Activated
  13. I wasn't on my computer when I replied a couple of minutes ago, but just in case:
  14. I'm sorry but it actually works for me. I just checked both my tunnels and they are detected a open.
  15. Not what I meant. To actually check that the port is in fact open. https://check-host.net/check-udp
  16. Honestly, I don't see this has been mentioned. But have you checked that the UDP port is opened?
  17. Awesome! Thanks. Ps. Did you read my reply with new information some posts back?
  18. Hey, so, disabled my bond, I actually just used eth0. Briding enabled only for eth0 too. Same thing happened, I tried grabbing diagnostics, but it said (https://share.getcloudapp.com/WnuE0Ljd): Starting diagnostics collection... I waited for 40 minutes and nothing, just more kernel panics in the logs. Here are the logs (pastebin as it's pretty large, same KP over and over again as far as I can tell): https://pastebin.com/gQd8P7Zt Thanks! edit: I created a new diagnostics set, from console after the restart and it took 5 seconds, so yeah. Attaching it in case it helps with anything. tower-diagnostics-20200105-1932.zip
  19. I will try that, question tho, how would I get the diagnostics before, if I can't access it? Thanks!
  20. @bonienl not sure if you missed my post in the previous page? Wireguard crashing my server.
  21. You are must welcome! Happy new year. Edit- Sorry to be a pain, but it still not working. The "basicjre.gzip.tar" extracts a "jre1.8.0_231" folder, and it's trying to find the java bin in the "basicjre" folder. Again, I just fixed it by renaming the folder. Pushed a PR in your repo.
  22. Hello @ich777, just wanted to let you know that your Mindustry Docker is trying to pull the java tar from your minecraft repo, which doesn't have the file anymore :). I just downloaded it manual and untar it and got it working, but just wanted to let you know.
  23. Hello, I started testing this yesterday. I added 3 different tunnels. I have 2 wans, so: - 1 Remote access to lan through wan1 - 1 Remote access to lan through wan2 - 1 Remove tunneled access through the wan1 I can connect and everything works perfectly fine, but it looks like when I disconnect and reconnect, or just connect with another tunnel, my server's network dies. I can't ping it anymore and there's some kernel panic logs: Jan 1 21:09:34 Tower kernel: ------------[ cut here ]------------ Jan 1 21:09:34 Tower kernel: NETDEV WATCHDOG: eth1 (igb): transmit queue 1 timed out Jan 1 21:09:34 Tower kernel: WARNING: CPU: 23 PID: 0 at net/sched/sch_generic.c:465 dev_watchdog+0x161/0x1bb Jan 1 21:09:34 Tower kernel: Modules linked in: wireguard ip6_udp_tunnel udp_tunnel nvidia_uvm(O) arc4 ecb md4 sha512_ssse3 sha512_generic cmac cifs ccm 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 ipt_MASQUERADE iptable_filter iptable_nat nf_nat_ipv4 nf_nat ip_tables xfs md_mod nct6775 hwmon_vid k10temp bonding igb i2c_algo_bit edac_mce_amd kvm_amd nvidia_drm(PO) nvidia_modeset(PO) nvidia(PO) ipmi_ssif kvm crct10dif_pclmul rsnvme(PO) crc32_pclmul crc32c_intel drm_kms_helper ghash_clmulni_intel drm pcbc aesni_intel agpgart wmi_bmof syscopyarea aes_x86_64 crypto_simd cryptd ahci sysfillrect sysimgblt ccp sr_mod pcc_cpufreq fb_sys_fops i2c_piix4 glue_helper libahci button ipmi_si cdrom acpi_cpufreq nvme i2c_core nvme_core Jan 1 21:09:34 Tower kernel: wmi [last unloaded: i2c_algo_bit] Jan 1 21:09:34 Tower kernel: CPU: 23 PID: 0 Comm: swapper/23 Tainted: P O 4.19.88-Unraid #1 Jan 1 21:09:34 Tower kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./X470D4U, BIOS P3.20 08/12/2019 Jan 1 21:09:34 Tower kernel: RIP: 0010:dev_watchdog+0x161/0x1bb Jan 1 21:09:34 Tower kernel: Code: 71 94 00 00 75 39 48 89 ef c6 05 38 71 94 00 01 e8 85 a8 fd ff 44 89 e9 48 89 ee 48 c7 c7 49 1f da 81 48 89 c2 e8 8f 1b af ff <0f> 0b eb 11 41 ff c5 48 81 c2 40 01 00 00 41 39 cd 75 95 eb 13 48 Jan 1 21:09:34 Tower kernel: RSP: 0018:ffff888ffebc3ea0 EFLAGS: 00010286 Jan 1 21:09:34 Tower kernel: RAX: 0000000000000000 RBX: ffff888ff679c438 RCX: 0000000000000007 Jan 1 21:09:34 Tower kernel: RDX: 00000000000005be RSI: 0000000000000002 RDI: ffff888ffebd64f0 Jan 1 21:09:34 Tower kernel: RBP: ffff888ff679c000 R08: 0000000000000003 R09: 000000000001cd00 Jan 1 21:09:34 Tower kernel: R10: 0000000000000000 R11: 0000000000000058 R12: ffff888ff679c41c Jan 1 21:09:34 Tower kernel: R13: 0000000000000001 R14: ffff888ff39ee940 R15: 0000000000000017 Jan 1 21:09:34 Tower kernel: FS: 0000000000000000(0000) GS:ffff888ffebc0000(0000) knlGS:0000000000000000 Jan 1 21:09:34 Tower kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jan 1 21:09:34 Tower kernel: CR2: 00007ffbffff8fc8 CR3: 0000000f93166000 CR4: 0000000000340ee0 Jan 1 21:09:34 Tower kernel: Call Trace: Jan 1 21:09:34 Tower kernel: <IRQ> Jan 1 21:09:34 Tower kernel: call_timer_fn+0x18/0x7b Jan 1 21:09:34 Tower kernel: ? qdisc_reset+0xc0/0xc0 Jan 1 21:09:34 Tower kernel: expire_timers+0x7e/0x8d Jan 1 21:09:34 Tower kernel: run_timer_softirq+0x72/0x120 Jan 1 21:09:34 Tower kernel: ? enqueue_hrtimer.isra.0+0x23/0x27 Jan 1 21:09:34 Tower kernel: ? __hrtimer_run_queues+0xdd/0x10b Jan 1 21:09:34 Tower kernel: ? ktime_get+0x44/0x95 Jan 1 21:09:34 Tower kernel: __do_softirq+0xc9/0x1d7 Jan 1 21:09:34 Tower kernel: irq_exit+0x5e/0x9d Jan 1 21:09:34 Tower kernel: smp_apic_timer_interrupt+0x80/0x93 Jan 1 21:09:34 Tower kernel: apic_timer_interrupt+0xf/0x20 Jan 1 21:09:34 Tower kernel: </IRQ> Jan 1 21:09:34 Tower kernel: RIP: 0010:cpuidle_enter_state+0xe8/0x141 Jan 1 21:09:34 Tower kernel: Code: ff 45 84 f6 74 1d 9c 58 0f 1f 44 00 00 0f ba e0 09 73 09 0f 0b fa 66 0f 1f 44 00 00 31 ff e8 e0 99 bb ff fb 66 0f 1f 44 00 00 <48> 2b 2c 24 b8 ff ff ff 7f 48 b9 ff ff ff ff f3 01 00 00 48 39 cd Jan 1 21:09:34 Tower kernel: RSP: 0018:ffffc90006423e98 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13 Jan 1 21:09:34 Tower kernel: RAX: ffff888ffebdfac0 RBX: ffff888ff1fd6400 RCX: 000000000000001f Jan 1 21:09:34 Tower kernel: RDX: 0000000000000000 RSI: 0000000021bf5be5 RDI: 0000000000000000 Jan 1 21:09:34 Tower kernel: RBP: 000038ac8d05b99b R08: 000038ac8d05b99b R09: 00000000000003b2 Jan 1 21:09:34 Tower kernel: R10: 00000000000ac1b8 R11: 071c71c71c71c71c R12: 0000000000000001 Jan 1 21:09:34 Tower kernel: R13: ffffffff81e5e260 R14: 0000000000000000 R15: ffffffff81e5e2d8 Jan 1 21:09:34 Tower kernel: ? cpuidle_enter_state+0xbf/0x141 Jan 1 21:09:34 Tower kernel: do_idle+0x17e/0x1fc Jan 1 21:09:34 Tower kernel: cpu_startup_entry+0x6a/0x6c Jan 1 21:09:34 Tower kernel: start_secondary+0x197/0x1b2 Jan 1 21:09:34 Tower kernel: secondary_startup_64+0xa4/0xb0 Jan 1 21:09:34 Tower kernel: ---[ end trace 47c27e2823999dc7 ]--- Jan 1 21:09:34 Tower kernel: igb 0000:24:00.0 eth1: Reset adapter If I wait a bit, it ends up resetting the adapter and I get a ping response again, however I can't access the UI or anything, there's another kernel panic in the logs immediatelly. Jan 1 21:09:34 Tower kernel: igb 0000:24:00.0 eth1: Reset adapter Jan 1 21:09:35 Tower kernel: igb 0000:24:00.0 eth1: igb: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX Jan 1 21:09:37 Tower kernel: igb 0000:24:00.0: exceed max 2 second Jan 1 21:10:25 Tower kernel: rcu: INFO: rcu_sched self-detected stall on CPU Jan 1 21:10:25 Tower kernel: rcu: 1-....: (60028 ticks this GP) idle=3d2/1/0x4000000000000002 softirq=7551290/7551290 fqs=14516 Jan 1 21:10:25 Tower kernel: rcu: (t=60000 jiffies g=22102957 q=73124) Jan 1 21:10:25 Tower kernel: NMI backtrace for cpu 1 Jan 1 21:10:25 Tower kernel: CPU: 1 PID: 8154 Comm: kworker/1:2 Tainted: P W O 4.19.88-Unraid #1 Jan 1 21:10:25 Tower kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./X470D4U, BIOS P3.20 08/12/2019 Jan 1 21:10:25 Tower kernel: Workqueue: wg-kex-wg2 wg_packet_handshake_receive_worker [wireguard] Jan 1 21:10:25 Tower kernel: Call Trace: Jan 1 21:10:25 Tower kernel: <IRQ> Jan 1 21:10:25 Tower kernel: dump_stack+0x67/0x83 Jan 1 21:10:25 Tower kernel: nmi_cpu_backtrace+0x71/0x83 Jan 1 21:10:25 Tower kernel: ? lapic_can_unplug_cpu+0x97/0x97 Jan 1 21:10:25 Tower kernel: nmi_trigger_cpumask_backtrace+0x57/0xd4 Jan 1 21:10:25 Tower kernel: rcu_dump_cpu_stacks+0x8b/0xb4 Jan 1 21:10:25 Tower kernel: rcu_check_callbacks+0x296/0x5a0 Jan 1 21:10:25 Tower kernel: update_process_times+0x24/0x47 Jan 1 21:10:25 Tower kernel: tick_sched_timer+0x36/0x64 Jan 1 21:10:25 Tower kernel: __hrtimer_run_queues+0xb7/0x10b Jan 1 21:10:25 Tower kernel: ? tick_sched_handle.isra.0+0x2f/0x2f Jan 1 21:10:25 Tower kernel: hrtimer_interrupt+0xf4/0x20e Jan 1 21:10:25 Tower kernel: smp_apic_timer_interrupt+0x7b/0x93 Jan 1 21:10:25 Tower kernel: apic_timer_interrupt+0xf/0x20 Jan 1 21:10:25 Tower kernel: </IRQ> Jan 1 21:10:25 Tower kernel: RIP: 0010:get_random_u32+0xd/0x89 Jan 1 21:10:25 Tower kernel: Code: 50 01 89 53 40 48 8b 04 c3 48 89 04 24 e8 0b 7d 28 00 48 8b 04 24 5a 5b 5d 41 5c c3 c3 0f 1f 44 00 00 ba 0a 00 00 00 0f c7 f0 <72> 79 ff ca 75 f7 41 54 48 c7 c2 b0 9f 29 82 48 c7 c7 80 66 c6 81 Jan 1 21:10:25 Tower kernel: RSP: 0018:ffffc9000d4cbd28 EFLAGS: 00000203 ORIG_RAX: ffffffffffffff13 Jan 1 21:10:25 Tower kernel: RAX: 00000000ffffffff RBX: ffff8889c7b7b2c8 RCX: 0000000000000000 Jan 1 21:10:25 Tower kernel: RDX: 000000000000000a RSI: 00000000fffffe01 RDI: ffffffffa02a1f38 Jan 1 21:10:25 Tower kernel: RBP: ffff8889bb300000 R08: ffffffffa02c89e0 R09: ffffc9000d4cbd18 Jan 1 21:10:25 Tower kernel: R10: ffffc9000d4cbe18 R11: 007e315c0363396c R12: ffff8889bb310000 Jan 1 21:10:25 Tower kernel: R13: ffff8889c7b7b2d0 R14: ffffc9000d4cbd68 R15: ffff8889c7b7b3a0 Jan 1 21:10:25 Tower kernel: ? wg_index_hashtable_insert+0x48/0x100 [wireguard] Jan 1 21:10:25 Tower kernel: wg_index_hashtable_insert+0x58/0x100 [wireguard] Jan 1 21:10:25 Tower kernel: wg_noise_handshake_create_response+0x23e/0x260 [wireguard] Jan 1 21:10:25 Tower kernel: wg_packet_send_handshake_response+0x3f/0xd0 [wireguard] Jan 1 21:10:25 Tower kernel: wg_packet_handshake_receive_worker+0x93/0x290 [wireguard] Jan 1 21:10:25 Tower kernel: process_one_work+0x16e/0x24f Jan 1 21:10:25 Tower kernel: worker_thread+0x1e2/0x2b8 Jan 1 21:10:25 Tower kernel: ? rescuer_thread+0x29e/0x29e Jan 1 21:10:25 Tower kernel: kthread+0x10c/0x114 Jan 1 21:10:25 Tower kernel: ? kthread_park+0x89/0x89 Jan 1 21:10:25 Tower kernel: ret_from_fork+0x22/0x40 I know the build is not stable, but I just wanted to know if I it's just that, or is there something else going on? Also attaching my diagnostics. Thank you. tower-diagnostics-20200101-2117.zip