4 ms·

I love systemd for deploying Golang, especially the security features, that systemd can own the TCP port for zero downtime deployments of the application and re

I love systemd for deploying Golang, especially the security features, that systemd can own the TCP port for zero downtime deployments of the application and restarts of a fail-fast application. It kind of replaced Docker (dockerd) which I've used with deploying Scala and TS.

xdfgh1112 4y ago
Hey, someone rediscovered xinetd
- klodolph 4y ago
  I remember using xinetd, and while xinetd does do the job… sometimes… systemd is much more comprehensive, so you don’t need to fuss about with different configs for xinetd, cron, init.d, etc. This is especially nice since the number of config options has skyrocketed, so systemd really simplifies administration (in my experience, at least).
- oblio 4y ago
  > Hey, someone rediscovered xinetd 1. http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd.html Replacing inetd was a systemd design goal. 2. Snark for someone learning is a bad move.
  - xdfgh1112 4y ago
    It was in jest, xinetd is clearly not as powerful as systemd and I'm glad to be rid of it.
- athrun 4y ago
  It's challenging to restart a service without dropping connections with xinetd. Even more so when the process is misbehaving, has children, and is not exiting cleanly.
- KingOfCoders 4y ago
  Isn't it astonishing? I've been using Linux pre-Slackware with downloading boot.tgz and root.tgz on two floppy drives, wrestled with M4 and sendmail, have been writing internet applications for 35+ years but never used a Linux daemon to manage my applications. You're never too old to learn I guess.
  - xdfgh1112 4y ago
    I use systemd at work and I have finally learned to love it. Still don't like binary logs but the timers, watchdog and sandboxing features are wonderful.
    - panzi 4y ago
      I configurated the systemd services at work to redirect the services' output to syslog.
- blueflow 4y ago
  I once won a backdoor contest by installing a systemd socket who launched /bin/sh as root. At this point, people don't question why systemd is being bound to some random ports.
  - biorach 4y ago
    were you able to install this without using sudo?
    - blueflow 4y ago
      In the contest you had root access for a limited amount of time, but you can also do it via a user unit.
      - Xylakant 4y ago
        But then you should only get the users account as shell, so while this is a neat trick, being able to gain persistent root if you are already root is not that hard.
        blueflow 4y ago
        It was part of the contest that your enemy team is not able to detect and remove your backdoor. The obscurity of systemd sockets was my winning move.
        wmrtynhber 4y ago
        systemd doesn't bind to random ports without being told to. if the blue team didn't stop and say "why is anything listening on port %d", they're a trash blue team.
        xorcist 4y ago
        Clearly you have not used systemd and friends much. It is an ecosystem of daemons that does a lot of things, some of which are guaranteed to surprise you. The specifics of which will vary between releases. I could easily see some random systemd utility binding a non standard port without anyone taking notice.
- vegai_ 4y ago
  >Hey, someone rediscovered xinetd With a much better piece of software, exactly.
mnutt 4y ago
It's great, you can have it launch multiple processes on the same port using SO_REUSEPORT. Normally it'd be a bit of a pain to health check multiple processes running on the same port without some other machinery since it is possible to get into a state where all but one process is hung. Systemd watchdog will provide your service with a socket and expect updates on a regular interval or else it will consider your service dead. This socket is also very handy for service startup, to have your process just notify systemd it is ready rather than having to poll to see if your process is listening yet.
b112 4y ago
own the TCP port for zero downtime deployments of the It's not zero downtime, if the app isn't reaponding. And any infra that cares about uptime, has redundant instances. This feature is, IMO, a feel good feature.
- dinosaurdynasty 4y ago
  It's zero downtime in that at no point does the kernel not respond to a TCP SYN packet and all those connections eventually get seen by the daemon. (Really useful for updating local services on Unix sockets.) It's also much simpler than redundant instances, and applications are updated much more commonly than hardware failures so it's a cheap way to increase availability in practice. And if your app can restart in a couple seconds... It might as well be zero downtime, and if not responding for a second is an issue, you have bigger issues.
  - b112 4y ago
    I believe that if a webpage (for example) doesn't download all resources, and be fully responsive in under 100ms, there is an issue. So maybe you think I have issues in general.
    - dinosaurdynasty 4y ago
      Using a server language with GC will break that. Using any kind of network that isn't hardwired to the server will break that. (Cellular, WiFi, roommate starts downloading an update over DSL, etc) Even just having other services on the server spike in usage can break that. Also I'm talking about "100% of requests finish in 100ms", which is damn near impossible, vs "99.9% of requests finish in 100ms", which is very doable and having a couple seconds a day you don't respond isn't going to break that.

xdfgh1112 4y ago

Hey, someone rediscovered xinetd

klodolph 4y ago
I remember using xinetd, and while xinetd does do the job… sometimes… systemd is much more comprehensive, so you don’t need to fuss about with different configs for xinetd, cron, init.d, etc. This is especially nice since the number of config options has skyrocketed, so systemd really simplifies administration (in my experience, at least).
oblio 4y ago
> Hey, someone rediscovered xinetd 1. http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd.html Replacing inetd was a systemd design goal. 2. Snark for someone learning is a bad move.
- xdfgh1112 4y ago
  It was in jest, xinetd is clearly not as powerful as systemd and I'm glad to be rid of it.
athrun 4y ago
It's challenging to restart a service without dropping connections with xinetd. Even more so when the process is misbehaving, has children, and is not exiting cleanly.
KingOfCoders 4y ago
Isn't it astonishing? I've been using Linux pre-Slackware with downloading boot.tgz and root.tgz on two floppy drives, wrestled with M4 and sendmail, have been writing internet applications for 35+ years but never used a Linux daemon to manage my applications. You're never too old to learn I guess.
- xdfgh1112 4y ago
  I use systemd at work and I have finally learned to love it. Still don't like binary logs but the timers, watchdog and sandboxing features are wonderful.
  - panzi 4y ago
    I configurated the systemd services at work to redirect the services' output to syslog.
blueflow 4y ago
I once won a backdoor contest by installing a systemd socket who launched /bin/sh as root. At this point, people don't question why systemd is being bound to some random ports.
- biorach 4y ago
  were you able to install this without using sudo?
  - blueflow 4y ago
    In the contest you had root access for a limited amount of time, but you can also do it via a user unit.
    - Xylakant 4y ago
      But then you should only get the users account as shell, so while this is a neat trick, being able to gain persistent root if you are already root is not that hard.
      - blueflow 4y ago
        It was part of the contest that your enemy team is not able to detect and remove your backdoor. The obscurity of systemd sockets was my winning move.
        wmrtynhber 4y ago
        systemd doesn't bind to random ports without being told to. if the blue team didn't stop and say "why is anything listening on port %d", they're a trash blue team.
        xorcist 4y ago
        Clearly you have not used systemd and friends much. It is an ecosystem of daemons that does a lot of things, some of which are guaranteed to surprise you. The specifics of which will vary between releases. I could easily see some random systemd utility binding a non standard port without anyone taking notice.
vegai_ 4y ago
>Hey, someone rediscovered xinetd With a much better piece of software, exactly.

mnutt 4y ago

It's great, you can have it launch multiple processes on the same port using SO_REUSEPORT. Normally it'd be a bit of a pain to health check multiple processes running on the same port without some other machinery since it is possible to get into a state where all but one process is hung. Systemd watchdog will provide your service with a socket and expect updates on a regular interval or else it will consider your service dead. This socket is also very handy for service startup, to have your process just notify systemd it is ready rather than having to poll to see if your process is listening yet.

b112 4y ago

own the TCP port for zero downtime deployments of the It's not zero downtime, if the app isn't reaponding. And any infra that cares about uptime, has redundant instances. This feature is, IMO, a feel good feature.

dinosaurdynasty 4y ago
It's zero downtime in that at no point does the kernel not respond to a TCP SYN packet and all those connections eventually get seen by the daemon. (Really useful for updating local services on Unix sockets.) It's also much simpler than redundant instances, and applications are updated much more commonly than hardware failures so it's a cheap way to increase availability in practice. And if your app can restart in a couple seconds... It might as well be zero downtime, and if not responding for a second is an issue, you have bigger issues.
- b112 4y ago
  I believe that if a webpage (for example) doesn't download all resources, and be fully responsive in under 100ms, there is an issue. So maybe you think I have issues in general.
  - dinosaurdynasty 4y ago
    Using a server language with GC will break that. Using any kind of network that isn't hardwired to the server will break that. (Cellular, WiFi, roommate starts downloading an update over DSL, etc) Even just having other services on the server spike in usage can break that. Also I'm talking about "100% of requests finish in 100ms", which is damn near impossible, vs "99.9% of requests finish in 100ms", which is very doable and having a couple seconds a day you don't respond isn't going to break that.