HomeSearchPrevious dayNext day

00:01:35qw3rty_ quits [Ping timeout: 272 seconds]
00:03:17qw3rty_ joins
01:19:12etnguyen03 (etnguyen03) joins
02:07:44<pabs>https://www.tomshardware.com/tech-industry/data-centers-turn-to-ex-airliner-engines-as-ai-power-crunch-bites
02:07:53tmg1|michelson joins
02:24:05Umbire quits [Ping timeout: 272 seconds]
02:28:34Umbire (Umbire) joins
02:30:51BornOn420 (BornOn420) joins
02:33:44<pabs>steering: re core dumps, just install systemd-coredump and send a SIGABRT/etc :)
02:39:50<pabs>nicolas17: was there more than @kde @kdecommunity on twitter? can you put them on the pad? https://pad.notkiska.pw/p/archivebot-twitter
02:40:26<nicolas17>there's an abandoned @kdesysadmin
03:06:55etnguyen03 quits [Remote host closed the connection]
03:11:49<nicolas17>https://store.apple.com/shop/Catalog/belfl/Images/ fun
03:16:36APOLLO03 quits [Ping timeout: 256 seconds]
03:57:20Zachava quits [Changing host]
03:57:20Zachava (Zachava) joins
05:32:42<steering>pabs: lmao, systemd
05:32:46<steering>no thank you :)
05:33:23<pabs>:) ok. its the best core dump handler so far I think
05:34:13<steering>fraknly i have no idea what a cored ump handler is or why someone would want one, my core dump handler is the kernel?
05:34:21<steering>but that's beside the point of systemd sucking :P
05:35:02<pabs>using one means your core dumps are managed rather than ending up in random directories all over your system
05:35:34<pabs>Linux has an option to pass dumps to a handler instead of just dumping to random dirs
05:35:38<steering>ah, yeah thats why i set core_pattern :)
05:36:03<pabs>you're starting to reinvent systemd-coredump I see :)
05:36:26<steering>erm, pretty sure core_pattern sysctl predates it by quite a while actually, so rather the other way around, not that that's surprising
05:37:50<steering>idk im pretty fine being able to just `gdb /usr/... /tmp/core`
05:39:11<steering>the prolbem i ran into doing it was just having it make a core dump in the first place since my typical core limit is 0
05:41:36<pabs>yep. the core dump handlers have quite a few more features than just core_pattern though. collecting metadata, security (multiuser, setuid, containers/namespaces etc), compression, automatic cleanup, etc
05:41:43<emanuele6>system 50
05:41:52<pabs>and the basics like enabling core dumps :)
05:42:07<emanuele6>coredumbctl gdb is awesome
05:53:37<steering>looking at systemd-coredump, it actually depends on the ulimit being set too :)
06:16:45emanuele6 quits [Read error: Connection reset by peer]
06:18:12sec^nd quits [Remote host closed the connection]
06:18:43sec^nd (second) joins
06:55:09midou quits [Ping timeout: 272 seconds]
06:56:42midou joins
07:32:00<pabs>steering: at least here, it sets those automatically: /etc/security/limits.d/20-coredump-debian.conf
07:32:18<pabs>hmm, limit is infinity...
07:41:14matoro quits [Ping timeout: 256 seconds]
07:49:54<steering>ye, that's just up to your distro
07:50:13<steering>I expect here on gentoo it'd have the same default limit whether systemd or not, could be wrong though
07:51:25<steering>to be fair, I actually wouldn't put it past systemd to solve one of the pains I had with making it coredump
07:52:20<steering>xinetd just setuid's and doesn't call pam (why would it) so pam_limits never triggers; systemd sockets might
07:53:08<steering>originally I set the limit just for the cgit user but ended up having to set it for * (and restart xinetd)
07:54:03<steering>other than that I was too lazy to go correlate the segfaults with access_log so I wasn't sure what was triggering it until I got the coredump, so I couldn't go trigger it myself :P
08:01:26matoro joins
09:04:03APOLLO03 joins
09:07:56rohvani quits [Ping timeout: 256 seconds]
09:47:26Dada joins
10:25:01Umbire quits [Quit: Umbire zaps a wand of digging!]
10:25:25APOLLO03 quits [Ping timeout: 272 seconds]
10:30:40APOLLO03 joins
10:30:40APOLLO03 quits [Client Quit]
10:32:44SootBector quits [Remote host closed the connection]
10:33:13APOLLO03 joins
10:33:52SootBector (SootBector) joins
10:36:40APOLLO03a joins
10:38:37APOLLO03a quits [Client Quit]
10:39:44APOLLO03 quits [Ping timeout: 256 seconds]
11:00:02Bleo182600722719623455222 quits [Quit: The Lounge - https://thelounge.chat]
11:02:48Bleo182600722719623455222 joins
11:04:44APOLLO03 joins
12:23:51balrog quits [Ping timeout: 272 seconds]
12:29:27balrog (balrog) joins
12:47:28Guest58 quits [Quit: My Mac has gone to sleep. ZZZzzz…]
15:17:23HackMii quits [Remote host closed the connection]
15:17:42HackMii (hacktheplanet) joins
16:36:33APOLLO03 quits [Ping timeout: 272 seconds]
16:39:05qw3rty_ quits [Ping timeout: 272 seconds]
16:39:19qw3rty_ joins
16:44:38Snivy quits [Quit: Ping timeout (120 seconds)]
16:44:56Snivy (Snivy) joins
17:32:46nine quits [Quit: See ya!]
17:33:01nine joins
17:33:01nine quits [Changing host]
17:33:01nine (nine) joins
17:36:15grill (grill) joins
17:39:15qw3rty_ quits [Ping timeout: 272 seconds]
17:39:42qw3rty_ joins
17:56:29<nicolas17>pabs: I still didn't manage to enable kernel panic logs :(
18:05:08qw3rty_ quits [Ping timeout: 256 seconds]
18:05:33qw3rty_ joins
19:02:22DogsRNice joins
19:06:01grill quits [Ping timeout: 272 seconds]
19:07:31grill (grill) joins
19:08:03lumidify quits [Quit: leaving]
19:09:19lumidify (lumidify) joins
19:31:21grill quits [Ping timeout: 272 seconds]
19:45:59APOLLO03 joins
20:13:40Umbire (Umbire) joins
20:14:29Umbire quits [Remote host closed the connection]
20:15:00Umbire (Umbire) joins
20:20:02Terbium quits [Quit: No Ping reply in 180 seconds.]
20:21:15Terbium joins
20:59:24etnguyen03 (etnguyen03) joins
21:16:55etnguyen03 quits [Client Quit]
21:31:19sec^nd quits [Ping timeout: 276 seconds]
21:35:47sec^nd (second) joins
22:01:07etnguyen03 (etnguyen03) joins
23:01:30Dada quits [Remote host closed the connection]
23:17:15atphoenix__ (atphoenix) joins
23:19:21atphoenix_ quits [Ping timeout: 272 seconds]
23:30:12Umbire quits [Read error: Connection reset by peer]
23:34:43pabs quits [Quit: Don't rest until all the world is paved in moss and greenery.]
23:45:52pabs (pabs) joins

HomeSearchPrevious dayNext day