6 ms·

Can anyone who's used systemd share what it's like to have it for process management? We use monit, and it's all right, but I occasionally wonder. Does anyone

by arjie 10y ago

Can anyone who's used systemd share what it's like to have it for process management? We use monit, and it's all right, but I occasionally wonder. Does anyone run it also as a separate user to manage certain applications? So that you could have certain people log on and operate some things and others operate other things?

deleted 10y ago
[deleted]
hornetblack 10y ago
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)
- deleted 10y ago
  [deleted]
- tophercyll 10y ago
  You can make user level systemd instances run at startup and stick around regardless of login/logout. loginctl enable-linger <username> This enables some nice deployment strategies that don't require root.
  - hornetblack 10y ago
    Thanks. I figured this was possible. I just never got around to looking at loginctl's options.
geocar 10y ago
Yes. I used to use runit/daemontools/inittab. My favourite thing about systemd is that it is increasingly available, and while it has it's faults, it has instances (macros you can use to kickoff a fleet of services easily) and pretty good isolation features. It also has a "systemctl-over-ssh" feature which is quite nice, and which allows you to use an .ssh/authorized_keys file instead of sudo to allow access to certain administrative tasks.
- arjie 10y ago
  Interesting. Thank you! Would you mind sharing some of the faults? By instances, are you referring to template unit files like this[0]? Do you use it with the `--user` option or do you just access it with `sudo systemctl`? 0: https://fedoramagazine.org/systemd-template-unit-files/ https://fedoramagazine.org/systemd-template-unit-files/
  - geocar 10y ago
    Yes, I do use --user where possible. Because resource limits are per-user on UNIX, I tend to run every program and every instance of a service as a separate user. cgroups/containers make this less necessary, but old habits die hard. The biggest systemd fault is one of tooling, and that just comes from a project ambitious enough to try and own it's own ecosystem. When runit/daemontools, you "debug" a service by typing: /path/to/service/run into the terminal. Everything is sensible: grep the output just works. You can use tools familiar like strace/dtruss to "look inside". A unix user can easily leverage their experiences to administer a small unix site, and grow their experiences into larger sites. With systemd, you run a unit file by copying it into a directory and run some (magic) commands. You need training/internet search to learn those commands. If your unit file doesn't work, you need more training/internet search, but systemd is still so new that your best bet may be to read the systemd source code, or insert a hacky "sleep 30" at the top of your start script and try to race and strace it in another window. Stuff like that. Want to upgrade your systemd unit? You can't run it along-side an existing version of itself unless you give it a new name, which changes how journalctl can pick up the results. Versioning in the unit name feels wrong, and nobody does this yet which still currently breaks live upgrades where the unit changes. Eventually the tooling will get better, but then we'll have a way to read files, and away to read systemd files; we'll have a way to run programs, and we'll have a way to run systemd programs; we'll have a way to "test" units, and a side-by-side mode, and so on.
    - arjie 10y ago
      Ah, hmm. Thank you very much for sharing. Looks like it's got some way before I can use it instead of `monit`. This helps a lot.
sandGorgon 10y ago
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 is much preferable to run it/supervisord
- bradmwalker 10y ago
  Systemd works inside LXC and systemd-nspawn.
- stephenr 10y ago
  > It matured at roughly the same time as docker. Docker, "matured", in past tense? Proof of time travel right there!
- chimeracoder 10y ago
  > 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 that you want to monitor, and systemd can be used either to monitor them or even to run the containers directly. (Yes, systemd can even run Docker containers directly, without Docker![1]) [0] you are using exec mode, right? [1] https://chimeracoder.github.io/docker-without-docker/#1 https://chimeracoder.github.io/docker-without-docker/#1
  - sandGorgon 10y ago
    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 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-zombie-reaping-problem/ https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zomb...
deleted 10y ago
[deleted]

by arjie 10y ago

deleted 10y ago

[deleted]

hornetblack 10y ago

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)

deleted 10y ago
[deleted]
tophercyll 10y ago
You can make user level systemd instances run at startup and stick around regardless of login/logout. loginctl enable-linger <username> This enables some nice deployment strategies that don't require root.
- hornetblack 10y ago
  Thanks. I figured this was possible. I just never got around to looking at loginctl's options.

geocar 10y ago

Yes. I used to use runit/daemontools/inittab. My favourite thing about systemd is that it is increasingly available, and while it has it's faults, it has instances (macros you can use to kickoff a fleet of services easily) and pretty good isolation features. It also has a "systemctl-over-ssh" feature which is quite nice, and which allows you to use an .ssh/authorized_keys file instead of sudo to allow access to certain administrative tasks.

arjie 10y ago
Interesting. Thank you! Would you mind sharing some of the faults? By instances, are you referring to template unit files like this[0]? Do you use it with the `--user` option or do you just access it with `sudo systemctl`? 0: https://fedoramagazine.org/systemd-template-unit-files/ https://fedoramagazine.org/systemd-template-unit-files/
- geocar 10y ago
  Yes, I do use --user where possible. Because resource limits are per-user on UNIX, I tend to run every program and every instance of a service as a separate user. cgroups/containers make this less necessary, but old habits die hard. The biggest systemd fault is one of tooling, and that just comes from a project ambitious enough to try and own it's own ecosystem. When runit/daemontools, you "debug" a service by typing: /path/to/service/run into the terminal. Everything is sensible: grep the output just works. You can use tools familiar like strace/dtruss to "look inside". A unix user can easily leverage their experiences to administer a small unix site, and grow their experiences into larger sites. With systemd, you run a unit file by copying it into a directory and run some (magic) commands. You need training/internet search to learn those commands. If your unit file doesn't work, you need more training/internet search, but systemd is still so new that your best bet may be to read the systemd source code, or insert a hacky "sleep 30" at the top of your start script and try to race and strace it in another window. Stuff like that. Want to upgrade your systemd unit? You can't run it along-side an existing version of itself unless you give it a new name, which changes how journalctl can pick up the results. Versioning in the unit name feels wrong, and nobody does this yet which still currently breaks live upgrades where the unit changes. Eventually the tooling will get better, but then we'll have a way to read files, and away to read systemd files; we'll have a way to run programs, and we'll have a way to run systemd programs; we'll have a way to "test" units, and a side-by-side mode, and so on.
  - arjie 10y ago
    Ah, hmm. Thank you very much for sharing. Looks like it's got some way before I can use it instead of `monit`. This helps a lot.

sandGorgon 10y ago

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 is much preferable to run it/supervisord

bradmwalker 10y ago
Systemd works inside LXC and systemd-nspawn.
stephenr 10y ago
> It matured at roughly the same time as docker. Docker, "matured", in past tense? Proof of time travel right there!
chimeracoder 10y ago
> 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 that you want to monitor, and systemd can be used either to monitor them or even to run the containers directly. (Yes, systemd can even run Docker containers directly, without Docker![1]) [0] you are using exec mode, right? [1] https://chimeracoder.github.io/docker-without-docker/#1 https://chimeracoder.github.io/docker-without-docker/#1
- sandGorgon 10y ago
  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 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-zombie-reaping-problem/ https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zomb...

deleted 10y ago

[deleted]