3 ms·

Nice move and nice write-up! There has been so much propaganda around serverless, so we need to hear more of these voices. I moved away from FreeBSD to Debian

Nice move and nice write-up! There has been so much propaganda around serverless, so we need to hear more of these voices. I moved away from FreeBSD to Debian for hosting my things because the process/daemon management was too tricky. You seem to have figured out a good solution, but I wanted something simpler like PM2 for automatic process management/restarting/logs. Unfortunately PM2 has an issue [1] that makes it unworkable with FreeBSD. It would be so nice if FreeBSD had a smooth, more declarative way of managing processes. 1. https://github.com/Unitech/pm2/issues/5718 https://github.com/Unitech/pm2/issues/5718

jmmv 11mo ago
Thanks! > I moved away from FreeBSD to Debian for hosting my things because the process/daemon management was too tricky. It indeed is tricky. To be honest, I wasn't "put off" by it because I've been using BSDs and old-style Linux startup systems for almost 30 years now... but the lack of abstraction shows, and I don't think it's great. The daemon(8) wrapper is neat to integrate pre-existing servers into rc.d, but I do not fancy having to deal with that "by hand" nor to create a shell script to manage my own service (related from a few years ago: https://jmmv.dev/2020/08/rcd-libexec-etc.html https://jmmv.dev/2020/08/rcd-libexec-etc.html) nor to have something entirely separate to manage log rotation. As much hate as systemd gets, I do think being declarative (and doing so in a DSL that's not a programming language) and having a true process "supervisor" is a better model. BUT, as I mentioned in this article, I also like the "no churn" of the BSDs because what I learned and refined over ~30 years is still similar to this day and that I won't be bitten by surprises.
- skydhash 10mo ago
  Not GP, but I do prefer the very direct control you get with rcctl (OpenBSD), openrc (Alpine),... Systemd often feels like autoconf. It's needed when you really want the capabilities, otherwise the opaqueness and complexity feels very much cumbersome when you're dealing with a simple service. I do like the Unix way of having different components handling different tasks instead of having different things which are entangled with each other. It encourages transparency.
- networked 10mo ago
  Even with daemon(8), PID files and the lack of process supervision might be my least favorite aspect of FreeBSD, an OS I like overall. Not long ago, I wanted to avoid running a custom service that way on a fresh FreeBSD server. After researching my options, I found an adequate solution in the daemontools family. I'd heard of daemontools but hadn't paid much attention to it. My service has been managed by runit and, most recently, nitro (https://github.com/leahneukirchen/nitro https://github.com/leahneukirchen/nitro). Both have run as the service's user. They supervise the process and handle logging. I have found the design of daemontools and its derivatives runit and nitro elegant; it lives up to the reputation.
  - adrian_b 10mo ago
    I have been using daemontools for managing my services on FreeBSD servers that have run 24/7 for almost a quarter of century, with down times of an hour or so only at intervals of a few years of continuous running, whenever I made a hardware upgrade or a complete OS replacement (by passing to another major version of FreeBSD). Now there are several daemontools derivatives that bring it more up-to-date, but even the ancient original version did most of one would need for reliable service management.
- yjftsjthsd-h 10mo ago
  > As much hate as systemd gets, I do think being declarative (and doing so in a DSL that's not a programming language) and having a true process "supervisor" is a better model. I've been playing with dinit for a bit now; it combines a lot of the nice advantages of systemd with a finite scope and being portable across OSs.
PunchyHamster 10mo ago
I remember having same problem with Linux, tried to compensate with Monit but it never just worked quite right. Systemd might add a bunch of unnecessary complexity in places, but for a sysadmin it's a fucking blessing. Just write one simple file, set binary, user, done, add some limitations and dependencies if you want to be fancy, set auto restart to true and It Just Works. Can even set some memory limits if you want to be fancy so any memory leak won't get you into too much trouble but just gets the service restarted

jmmv 11mo ago

Thanks! > I moved away from FreeBSD to Debian for hosting my things because the process/daemon management was too tricky. It indeed is tricky. To be honest, I wasn't "put off" by it because I've been using BSDs and old-style Linux startup systems for almost 30 years now... but the lack of abstraction shows, and I don't think it's great. The daemon(8) wrapper is neat to integrate pre-existing servers into rc.d, but I do not fancy having to deal with that "by hand" nor to create a shell script to manage my own service (related from a few years ago: https://jmmv.dev/2020/08/rcd-libexec-etc.html https://jmmv.dev/2020/08/rcd-libexec-etc.html) nor to have something entirely separate to manage log rotation. As much hate as systemd gets, I do think being declarative (and doing so in a DSL that's not a programming language) and having a true process "supervisor" is a better model. BUT, as I mentioned in this article, I also like the "no churn" of the BSDs because what I learned and refined over ~30 years is still similar to this day and that I won't be bitten by surprises.

skydhash 10mo ago
Not GP, but I do prefer the very direct control you get with rcctl (OpenBSD), openrc (Alpine),... Systemd often feels like autoconf. It's needed when you really want the capabilities, otherwise the opaqueness and complexity feels very much cumbersome when you're dealing with a simple service. I do like the Unix way of having different components handling different tasks instead of having different things which are entangled with each other. It encourages transparency.
networked 10mo ago
Even with daemon(8), PID files and the lack of process supervision might be my least favorite aspect of FreeBSD, an OS I like overall. Not long ago, I wanted to avoid running a custom service that way on a fresh FreeBSD server. After researching my options, I found an adequate solution in the daemontools family. I'd heard of daemontools but hadn't paid much attention to it. My service has been managed by runit and, most recently, nitro (https://github.com/leahneukirchen/nitro https://github.com/leahneukirchen/nitro). Both have run as the service's user. They supervise the process and handle logging. I have found the design of daemontools and its derivatives runit and nitro elegant; it lives up to the reputation.
- adrian_b 10mo ago
  I have been using daemontools for managing my services on FreeBSD servers that have run 24/7 for almost a quarter of century, with down times of an hour or so only at intervals of a few years of continuous running, whenever I made a hardware upgrade or a complete OS replacement (by passing to another major version of FreeBSD). Now there are several daemontools derivatives that bring it more up-to-date, but even the ancient original version did most of one would need for reliable service management.
yjftsjthsd-h 10mo ago
> As much hate as systemd gets, I do think being declarative (and doing so in a DSL that's not a programming language) and having a true process "supervisor" is a better model. I've been playing with dinit for a bit now; it combines a lot of the nice advantages of systemd with a finite scope and being portable across OSs.

PunchyHamster 10mo ago

I remember having same problem with Linux, tried to compensate with Monit but it never just worked quite right. Systemd might add a bunch of unnecessary complexity in places, but for a sysadmin it's a fucking blessing. Just write one simple file, set binary, user, done, add some limitations and dependencies if you want to be fancy, set auto restart to true and It Just Works. Can even set some memory limits if you want to be fancy so any memory leak won't get you into too much trouble but just gets the service restarted