Post B5G6abNHEZnJzzWIka by nu@she-a.eu
(DIR) More posts by nu@she-a.eu
(DIR) Post #B5Fp8d6rUTiI3Fuyqe by navi@social.vlhl.dev
2 likes, 0 repeats
pid: 2148769i think my computer has been on for too long
(DIR) Post #B5Fp8dFMyqWETdtm6q by mia@movsw.0x0.st
1 likes, 0 repeats
@navi been noticing that after system updates when texlive is installed. they’re doing something insane with installed fonts nowhaving my iosevka variant installed makes those scripts take hours to complete lol
(DIR) Post #B5FqJI9npdrGCwwRNo by lanodan@queer.hacktivis.me
0 likes, 0 repeats
@navi Made me wonder what's the maximum value for kernel.pid_max, answer's PID_MAX_LIMIT in /usr/src/linux/include/linux/threads.h
(DIR) Post #B5FqfdGm17NQ3dr42C by navi@social.vlhl.dev
0 likes, 0 repeats
@lanodan looking at that file, seems to be 4194304 on 64bit systems, 0x400000which is quite a few, tho with 6 days of uptime, i might be just another week away from the pid rollover (not that i’m much worried about pid reuse)
(DIR) Post #B5FqfdPHVUBMU1prIO by lanodan@queer.hacktivis.me
0 likes, 0 repeats
@navi Yeah, I kept it to the default on all my machines but well I'd kind of rather would have a high pid limit given the amount of stuff still using pidfiles and the like.
(DIR) Post #B5Ft9snN3acQo1ed1M by fiore@brain.worm.pink
0 likes, 0 repeats
@navi now im wondering if PIDs can overflow .. and what happens if they do ..
(DIR) Post #B5FtGTVnSUa8PxZrua by fiore@brain.worm.pink
0 likes, 0 repeats
@navi oh . nvm theres an answer already
(DIR) Post #B5FtJvbtRic6Qq4l7o by navi@social.vlhl.dev
1 likes, 0 repeats
@fiore yes, though not likely an overflow, but once it reaches kernel.pid_max (see https://social.vlhl.dev/notice/B5FqXqKZfAwq8VVpc8), it wraps around to the lowest unused pidwhich is why pidfiles are bad for daemon management
(DIR) Post #B5FtLt2fxsvv2wXMAa by fiore@brain.worm.pink
0 likes, 0 repeats
@navi uhh what are pidfiles ..
(DIR) Post #B5FtRUF55E2Nru0fBI by navi@social.vlhl.dev
1 likes, 0 repeats
@fiore my server has ~500 days uptime, and the pid is currently at 88110, so it already looped a few times at least
(DIR) Post #B5G6WA9yTWkmR6BIKu by navi@social.vlhl.dev
1 likes, 0 repeats
@fiore older systems (and sadly some modern ones, as much as i'm trying to stop that habit in openrc, and most bsds still do this too), would have daemons start, fork to the background, and write their pid to a file, usually in /runand then when you tell the init script to stop the given service, it would read the pidfile, (hopefully do some sanity checks), then send a TERM or KILL signal to that processbut then what happens if said daemon crashes, the pid wraps around, and something else is started under the pid written to that file? with luck the sanity checks make the operation fail, without luck you kill a random unrelated processmodern solution is called supervision, you run the daemons directly under a supervisor, without background forking -- so that you don't have to rely on a file that might get stale
(DIR) Post #B5G6Wm9xC3JeI2Soa0 by fiore@brain.worm.pink
0 likes, 0 repeats
@navi i see… thats cool
(DIR) Post #B5G6aVUr5UI7ll1GjI by wyatt@soc.megatokyo.moe
1 likes, 0 repeats
@navi @fiore only 30 on mine because no UPS and power failures :(
(DIR) Post #B5G6abNHEZnJzzWIka by nu@she-a.eu
1 likes, 0 repeats
@fiore @navi opens terminal that overflows to 0
(DIR) Post #B5G6i7vmaWHizxFREO by lispi314@udongein.xyz
0 likes, 0 repeats
@navi @fiore What was the reason for having the daemons fork anyway?
(DIR) Post #B5G6i8EZSfJVwE2RW4 by fiore@brain.worm.pink
0 likes, 0 repeats
@lispi314 @navi wdym?? what else would you do without a supervisor ?
(DIR) Post #B5G75ETePoFHxg6hpg by lispi314@udongein.xyz
0 likes, 0 repeats
@fiore @navi Why was there ever a pattern where daemons aren't managed by a supervisor?What led to that engineering decision?
(DIR) Post #B5G75Eg3fgAca9ucAi by fiore@brain.worm.pink
0 likes, 0 repeats
@lispi314 @navi because they dont need to ? its simpler implementation wise to just let them roam free
(DIR) Post #B5G9MOkxeONSfnW6tc by navi@social.vlhl.dev
1 likes, 0 repeats
@lispi314 @fiore system-v unix (and earlier, i think?) having /etc/rc be a shell script that is just executed, bsd followed suit, kinda -- you just add execution of the daemon binary in thereif you're not considering that daemons will crash, and not thinking much about stopping them, then just having them start and then fork themselves off makes senseso in an utopia of computing where nothing crashes unexpectedly, it might be simpler to just let daemons be by itself, not in our world though, but it took a while for people to learn that (and some people still didn't, claiming that instead of supervision we should "just" fix all crashes, who needs reliability anyway??)
(DIR) Post #B5G9MP5WPwp9hZ8Wwa by lanodan@queer.hacktivis.me
0 likes, 0 repeats
@navi @fiore @lispi314 This thing of dæmons handling all crashes reminds me of how often I've seen python dæmons have a catch all for exceptions into main, which is terribly ugly and can make it a pain to debug or even notice errors at all.Instead just crash when a critical error happens and let supervision and rest of the OS do it's job (alerting, pushing the coredump to another server for post-mortem, …).
(DIR) Post #B5GAZe30D5fboeptBI by lispi314@udongein.xyz
1 likes, 0 repeats
@navi @fiore > (and some people still didn't, claiming that instead of supervision we should "just" fix all crashes, who needs reliability anyway??)This makes both the Erlang and Lisp programmer parts of my brain unhappy.
(DIR) Post #B5GAfd3smvoeUp6KYq by ska@social.treehouse.systems
1 likes, 0 repeats
@lispi314 @fiore @navi To be fully honest, what led to that engineering decision is historical reasons. The Unix userspace was evolved more than designed; people who worked on it in the early days (and early lasted all the way to the late 90s) had no idea of good practices and/or they always needed the quick and dirty fix.So: inits had no supervisors because a supervisor is kinda difficult to write, so daemons were on their own. The rc script could only launch them in the background because it had to continue... and so, to make this "easier" on the rc script, a lot of daemons auto-backgrounded. They also made sure to detach from the console/tty in order to avoid polluting it with error messages, but they still needed a place to send their logs to, and that's why syslog was born.We have all the mistakes of history to deconstruct and correct. And if there's one thing to be said for systemd, it's that it has helped in that regard, bringing supervision to the mainstream. (They will claim they invented it but they obviously didn't 😅)
(DIR) Post #B5GB67fZbxc2xDMcHA by ska@social.treehouse.systems
1 likes, 0 repeats
@lanodan @fiore @navi @lispi314 Yeah, there are also a lot of products that come with their own half-assed supervision thing, which isn't a terrible idea when they need to work across a large swath of systems, but makes it difficult to cleanly integrate them into a distro or system with better supervision mechanisms already in place.It's old now, but whenever I had to deal with pppd, I had to spend more effort stripping the layers of init scripts that were useless to me and getting the daemon to run properly under my supervisor than building the thing (and in the early days building it was not easy).
(DIR) Post #B5GF9LGHvqNDnLKMM4 by wyatt@soc.megatokyo.moe
1 likes, 0 repeats
@navi @fiore @lispi314 a system that doesn't crash is reliablebut i know the point you are trying to make about real-world software
(DIR) Post #B5GKziDGLQS3o1hgLA by lispi314@udongein.xyz
1 likes, 0 repeats
@wyatt @fiore @navi Sometimes memory fails, sometimes the datacenter is hit by an object causing sparks, sometimes the hardware is just fundamentally broken (lol Intel CPUs).Graceful handling of failure must always be a consideration.