00:33:29kdqep (kdqep) joins
01:05:40Minkafighter quits [Remote host closed the connection]
01:07:16Minkafighter joins
01:36:36Meli quits [Ping timeout: 265 seconds]
01:57:23Meli (Meli) joins
02:27:23gazorpazorp quits [Quit: Leaving]
02:27:33gazorpazorp (gazorpazorp) joins
02:36:53Meli quits [Ping timeout: 265 seconds]
03:05:42Meli (Meli) joins
03:36:49Meli quits [Ping timeout: 265 seconds]
03:49:29Meli (Meli) joins
04:24:31eroc1990 quits [Quit: Ping timeout (120 seconds)]
04:25:20eroc1990 (eroc1990) joins
04:35:47Meli quits [Ping timeout: 265 seconds]
05:28:13Meli (Meli) joins
05:32:17qwertyasdfuiopghjkl quits [Client Quit]
05:36:49Meli quits [Ping timeout: 265 seconds]
05:44:39qwertyasdfuiopghjkl joins
06:07:26HackMii_ (hacktheplanet) joins
06:08:13HackMii quits [Ping timeout: 252 seconds]
06:19:28Meli (Meli) joins
07:33:10JackThompson quits [Ping timeout: 265 seconds]
09:57:16wessel1512 quits [Client Quit]
11:18:36wessel1512 joins
11:49:30JackThompson joins
12:08:05HackMii_ is now known as HackMii
13:55:09LeGoupil joins
14:25:07LeGoupil quits [Client Quit]
15:47:02Minkafighter quits [Remote host closed the connection]
15:47:35Minkafighter joins
15:48:37Minkafighter quits [Remote host closed the connection]
15:49:50Minkafighter joins
15:51:07Minkafighter quits [Remote host closed the connection]
15:53:10Minkafighter joins
15:55:09Minkafighter quits [Remote host closed the connection]
15:55:54Atom-- joins
15:56:49Minkafighter joins
15:57:46Atom quits [Ping timeout: 265 seconds]
15:58:31Minkafighter quits [Remote host closed the connection]
15:59:40Minkafighter joins
16:03:05Minkafighter quits [Remote host closed the connection]
16:08:29Minkafighter joins
16:11:31Minkafighter quits [Remote host closed the connection]
16:14:20Minkafighter joins
17:10:21billy549 (Billy549) joins
17:12:49billy549- quits [Ping timeout: 265 seconds]
17:14:47DigitalDragon quits [Quit: Reconnecting]
17:22:29billy549 quits [Ping timeout: 265 seconds]
17:43:03billy549 (Billy549) joins
17:57:48fuzzy8021 quits [Read error: Connection reset by peer]
17:58:55niku joins
17:59:02fuzzy8021 (fuzzy8021) joins
17:59:27niku quits [Client Quit]
18:11:26niku joins
18:18:30niku quits [Client Quit]
18:23:06niku joins
18:23:28niku quits [Client Quit]
18:28:59DigitalDragon (DigitalDragon) joins
18:48:25niku joins
18:51:20Matthww quits [Client Quit]
18:52:10Matthww joins
19:05:18kdqep quits [Ping timeout: 265 seconds]
19:37:49qwertyasdfuiopghjkl quits [Ping timeout: 265 seconds]
20:36:05@Fusl quits [Excess Flood]
20:36:21Fusl (Fusl) joins
20:36:21@ChanServ sets mode: +o Fusl
20:52:11r000t joins
20:52:40<r000t>Hi, my warrior VMs stop after a few days of running. I can't find anything specific in libvirt's logs. Are they shutting themselves down?
20:55:52<@JAA>I don't think that's a thing, no.
20:56:25<r000t>Does the warrior itself store logs?
20:57:01<@JAA>The warrior VM is a thin wrapper around the warrior Docker container, which should have some logs I think.
20:57:28<@JAA>At least I think that's how it works. I never used the warrior myself.
20:57:40<r000t>Alright. My first assumption is that it was told to shutdown by the project or something
21:03:04<@JAA>Yeah, pretty sure nothing like that has ever existed. The warrior just automatically switches between projects as we change it on the backend, but that's as far as it gets for control.
21:03:49<@JAA>OOM killer might be an option, but that should just kill the wget process, not the supporting code or the entire VM.
21:11:47<r000t>What I'm seeing is a process exiting and being restarted (/root/watchtower-logs.sh) a few times per minute, and then eventually `/sbin/openrc shutdown` is called
21:14:21<@JAA>Hmm, I see we have very high-quality code here: https://github.com/ArchiveTeam/Ubuntu-Warrior/blob/9c112fa3465e0737df0fce8619c562b033e20373/startup.sh#L134
21:15:01<r000t>lmao
21:17:24<@JAA>Not sure about watchtower-logs.sh restarting though. That should just run continuously once watchtower is started.
21:18:41<r000t>and again, this isn't a one-off thing. Both VMs I run stop, at the same time. It happening after an update fits with that pattern.
21:19:56<@JAA>When did that last happen?
21:21:08<r000t>The beginning of /var/log/messages is Apr 11 07:46:29, but it could have started before then. Apr 11 08:09:26 is when the shutdown happened.
21:21:23<@JAA>Uh yeah, there definitely wasn't an image update anywhere near that.
21:23:25<@JAA>The last build of the warrior Docker image was back in January, actually. Pretty sure it handles all the project stuff inside that, but even project changes were last done on 31 Mar (change of default project) or even earlier (code changes).
21:29:59<r000t>Think I solved the mystery, this was in warrior.log
21:29:59<r000t>2022-04-11 07:57:16,509 - seesaw.warrior - INFO - Running for more than 7 days. Time to schedule a reboot.
21:30:26<r000t>But if that's in a docker container, should that, as you mentioned, just restart the container and not the whole VM?
21:33:37<@JAA>Huh
21:35:37<@JAA>It should trigger a reboot of the VM. Definitely not a shutdown though.
21:36:32<@JAA>It writes a file to /tmp inside the container, which gets checked from startup.sh to do the VM reboot.
22:33:20@arkiver quits [Remote host closed the connection]
22:33:45arkiver (arkiver) joins
22:33:45@ChanServ sets mode: +o arkiver