Hacker News Reader

Comment by KingOfCoders | Hacker News Reader

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.

View on HN

Hey, someone rediscovered xinetd

> Hey, someone rediscovered xinetd

1. http://0pointer.de/blog/projects/systemd.html

Replacing inetd was a systemd design goal.

2. Snark for someone learning is a bad move.

It was in jest, xinetd is clearly not as powerful as systemd and I'm glad to be rid of it.

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.

were you able to install this without using sudo?

In the contest you had root access for a limited amount of time, but you can also do it via a user unit.

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.

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.

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.

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.

That would be the distro's problem, not systemd. Any of those utilities are going to be optional, the distro has to consciously enable them and ship them in a package for it to make it to you at all. A lot of commenters seem to misunderstand that systemd is not forcing distros to do anything. All they really do is provide a set of tools for distro maintainers to choose from.

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).

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.

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.

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.

I configurated the systemd services at work to redirect the services' output to syslog.

>Hey, someone rediscovered xinetd

With a much better piece of software, exactly.

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.

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.

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.

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.

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.

Reply on news.ycombinator.com