Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Real-time notifications from systemd to Slack

scaledrone.com

Post reply on HN
Print view View original

51–55 of 55 posts

Re: Real-time notifications from systemd to Slack

#51

Post by JdeBP »

fnord123 wrote: post #11
Curious42 wrote: post #9

Is Systemd a nohup equivalent? If it is, then what's the benefit of using one over the other?

nohup just runs a process that will ignore SIGHUP. systemd can also run processes that ignore SIGHUP. But systemd does a lot of things that nohup doesn't do. Please don't attempt to use nohup as a daemon management system for anything but the noddiest of tasks. If you're going to use anything, you're probably best choosing from this list: https://en.wikipedia.org/wiki/Operating_system_service_manag...

... which misses out quite a lot, from s6 through perp to initng.

Re: Real-time notifications from systemd to Slack

#52

Post by hornetblack »

tophercyll wrote: post #23
hornetblack wrote: post #18

Earlier quoted context omitted.

systemd has --user option, which makes it a service manager for a particular user, if that's what you mean. I used it for some time to run an emacs daemon. (until I found that it closed between logouts and changed to using the system manager isntead)

You can make user level systemd instances run at startup and stick around regardless of login/logout. loginctl enable-linger This enables some nice deployment strategies that don't require root.

Thanks. I figured this was possible. I just never got around to looking at loginctl's options.

Re: Real-time notifications from systemd to Slack

#53

Post by sandGorgon »

chimeracoder wrote: post #44
sandGorgon wrote: post #29

Earlier quoted context omitted.

systemd is far superior to anything else out there. It matured at roughly the same time as docker. However it doesn't support being the CMD in a Dockerfile. Which is why it's not very common in software deployment scenarios in the post-container world. For older deployments, it may not be worth switching to systemd because the base OS may not be compatible. So it's kind of a catch-22. If you are on baremetal, systemd…

> However it doesn't support being the CMD in a Dockerfile. Which is why it's not very common in software deployment scenarios in the post-container world. Er, that's only half-true. systemd isn't great for running as PID 1 inside a Dockerfile, but that's because Docker already monitors PID 1[0], and systemd can be used to monitor your container itself. In other words, think of containers as individual applications t…

Actually I'm not sure we are referring to the same thing here.

I'm referring to pid1 inside the docker container. systemd does not run inside the container as pid1 very easily.

Take a look at this - https://github.com/docker/docker/pull/13525

I think your presentation was about replicating docker functionality using systemd-nspawn...Which pretty cool...But it's not the same as what I'm talking about.

I'm referring more generally to production decisions with docker. Also read this https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zomb...

Re: Real-time notifications from systemd to Slack

#54

Post by chimeracoder »

sandGorgon wrote: post #53
chimeracoder wrote: post #44

Earlier quoted context omitted.

> However it doesn't support being the CMD in a Dockerfile. Which is why it's not very common in software deployment scenarios in the post-container world. Er, that's only half-true. systemd isn't great for running as PID 1 inside a Dockerfile, but that's because Docker already monitors PID 1[0], and systemd can be used to monitor your container itself. In other words, think of containers as individual applications t…

Actually I'm not sure we are referring to the same thing here. I'm referring to pid1 inside the docker container. systemd does not run inside the container as pid1 very easily. Take a look at this - https://github.com/docker/docker/pull/13525 I think your presentation was about replicating docker functionality using systemd-nspawn...Which pretty cool...But it's not the same as what I'm talking about. I'm referring mo…

> Actually I'm not sure we are referring to the same thing here. I'm referring to pid1 inside the docker container. systemd does not run inside the container as pid1 very easily.

We are - I'm saying that you don't actually want to run systemd as PID 1 inside a Docker container; the Docker model is built around the container being an application unit, not a system unit.

But if you want to have isolated system(d) units, you can use systemd to get that behavior inside containers. In that case, you'll want to use systemd to run your containers instead of Docker, because systemd's tooling is container-aware (ie, you can have integration between units that run on your host and units that run inside a machine - 'machine' being the systemd term for 'container', in this case).

Re: Real-time notifications from systemd to Slack

#55

Post by sandGorgon »

chimeracoder wrote: post #54
sandGorgon wrote: post #53

Earlier quoted context omitted.

Actually I'm not sure we are referring to the same thing here. I'm referring to pid1 inside the docker container. systemd does not run inside the container as pid1 very easily. Take a look at this - https://github.com/docker/docker/pull/13525 I think your presentation was about replicating docker functionality using systemd-nspawn...Which pretty cool...But it's not the same as what I'm talking about. I'm referring mo…

> Actually I'm not sure we are referring to the same thing here. I'm referring to pid1 inside the docker container. systemd does not run inside the container as pid1 very easily. We are - I'm saying that you don't actually want to run systemd as PID 1 inside a Docker container; the Docker model is built around the container being an application unit, not a system unit. But if you want to have isolated system(d) units…

That is a simplification - even Facebook runs sshd inside its containers.

I know what you are saying - that an atomic unit of work is the program itself..But we run stuff under supervisord even if it is a single program. It helps us to make quick debugging changes to scripts,etc and "restart" them without restarting the container.

In theory it seems the same - in practice it is not. This is the reason for the existence of tons of different init tools for docker.

BTW, I had trouble understanding what you meant because you are constantly moving from docker-as-an-application-unit concept (which is reasonably true) to systemd-nspawn-is-better-than-docker (which is something I am not generally opinionated about).

Post reply on HN