4 ms·

> simple This might look simple, because "Hello world" is simple in most languages. But if you really work with them, you will encounter many hidden complexiti

by chme 10y ago

> simple This might look simple, because "Hello world" is simple in most languages. But if you really work with them, you will encounter many hidden complexities.

rkangel 10y ago
I've written a few daemons now, and the files haven't been a lot more complicated, and the extensions have been obvious (I need to give this process some capabilities, ok set CAPABILITY_BOUNDING_SET). Systemd being responsible for daemonising also removes several corner cases I could screw up on daemon implementation and saved me time. All in all I had a much easier experience that I did with similar tasks on SysV.
viraptor 10y ago
No, I meant it. I wrote the service files for a number of services and they usually come down to exactly this. Sometimes they require more attention if you want to get more out of systemd. For example socket activation requires proper handling in the app's source code. And if you want to use cgroups, you have to know how they work. But in practice, the description of all of that is still simple. Have a look at your service descriptions in /usr/lib/systemd/system - there will be a few services with crazy dbus activation and a long list of options, but most of the others are quite simple and the extra options are only to make it work better, not to make it work in general. And being able to simply set things like NoNewPrivileges, MemoryDenyWriteExecute, and Protect* without going into LSM profiles is a great simplification.
- chme 10y ago
  Okay, then maybe the complexity doesn't come from the .service/.socket files but from the used mechanisms. A colleague of mine had the problem that one of his applications was shut down because the user context which this service belonged to, logged out/disconnected (I think it was a system user). So he had to hack something together to ensure that the service is not affected by this.
  - ZZBop 10y ago
    Or just add 'KillUserProcesses=no' to /etc/systemd/logind.conf.
    - kuschku 10y ago
      And then logout and login again, and have 200 sessions of shitty daemons like megasync or dropbox in your process manager. No thanks.
      - ZZBop 10y ago
        Individual daemons can be tuned with systemd-run/loginctl linger - but I guess posting snarky comments on HN is way more constructive than RTFM.
        kuschku 10y ago
        Yes, exactly. That’s how it’s supposed to be: Everything is killed by default, and you have to elevate it with systemd-run to make it work properly. Allowing any process to linger around by default is just stupid, which is why "Or just add 'KillUserProcesses=no' to /etc/systemd/logind.conf." is as horrible advice as "just add your own user to the root group".
        digi_owl 10y ago
        In other words, systemd has reinvented nohup and crew...
        kuschku 10y ago
        Except, this time with a working permission system, and proper limits per user. That’s something no other competitor has provided before.
  - MertsA 10y ago
    So what you're referring to is that he had some unit started within some user's scope and then killed the scope which promptly stopped his unit. This behavior was actually not the default on most distros until not too terribly long ago. Basically, the way this used to work was that on logout, all of the user's processes would get signaled that they need to close but it was up to the application to handle how to respond to that signal. Sometimes daemons would misbehave and there's nothing to differentiate "this app is supposed to end but hasn't" and "this app is choosing to ignore the signal because it needs to stay running". With systemd, there is an option to reap these processes so that when you log out, you never have to worry about some misbehaving process hanging around and causing problems when you log back in. The way to fix this without disabling the feature is by explicitly putting the process in it's own scope. That doesn't take special permissions to do, it's just that it needs to be done explicitly instead of just ignoring SIGHUP.
vacri 10y ago
I've written a few unit files, including some edge cases like binding one service to another, and it's just a few more key/value pairs. This being said, upstart has a similarly simple setup. Any time I have to fiddle with sysv init files, I long for either of upstart or systemd.

by chme 10y ago

> simple This might look simple, because "Hello world" is simple in most languages. But if you really work with them, you will encounter many hidden complexities.

rkangel 10y ago

I've written a few daemons now, and the files haven't been a lot more complicated, and the extensions have been obvious (I need to give this process some capabilities, ok set CAPABILITY_BOUNDING_SET). Systemd being responsible for daemonising also removes several corner cases I could screw up on daemon implementation and saved me time. All in all I had a much easier experience that I did with similar tasks on SysV.

viraptor 10y ago

No, I meant it. I wrote the service files for a number of services and they usually come down to exactly this. Sometimes they require more attention if you want to get more out of systemd. For example socket activation requires proper handling in the app's source code. And if you want to use cgroups, you have to know how they work. But in practice, the description of all of that is still simple. Have a look at your service descriptions in /usr/lib/systemd/system - there will be a few services with crazy dbus activation and a long list of options, but most of the others are quite simple and the extra options are only to make it work better, not to make it work in general. And being able to simply set things like NoNewPrivileges, MemoryDenyWriteExecute, and Protect* without going into LSM profiles is a great simplification.

chme 10y ago
Okay, then maybe the complexity doesn't come from the .service/.socket files but from the used mechanisms. A colleague of mine had the problem that one of his applications was shut down because the user context which this service belonged to, logged out/disconnected (I think it was a system user). So he had to hack something together to ensure that the service is not affected by this.
- ZZBop 10y ago
  Or just add 'KillUserProcesses=no' to /etc/systemd/logind.conf.
  - kuschku 10y ago
    And then logout and login again, and have 200 sessions of shitty daemons like megasync or dropbox in your process manager. No thanks.
    - ZZBop 10y ago
      Individual daemons can be tuned with systemd-run/loginctl linger - but I guess posting snarky comments on HN is way more constructive than RTFM.
      - kuschku 10y ago
        Yes, exactly. That’s how it’s supposed to be: Everything is killed by default, and you have to elevate it with systemd-run to make it work properly. Allowing any process to linger around by default is just stupid, which is why "Or just add 'KillUserProcesses=no' to /etc/systemd/logind.conf." is as horrible advice as "just add your own user to the root group".
        digi_owl 10y ago
        In other words, systemd has reinvented nohup and crew...
        kuschku 10y ago
        Except, this time with a working permission system, and proper limits per user. That’s something no other competitor has provided before.
- MertsA 10y ago
  So what you're referring to is that he had some unit started within some user's scope and then killed the scope which promptly stopped his unit. This behavior was actually not the default on most distros until not too terribly long ago. Basically, the way this used to work was that on logout, all of the user's processes would get signaled that they need to close but it was up to the application to handle how to respond to that signal. Sometimes daemons would misbehave and there's nothing to differentiate "this app is supposed to end but hasn't" and "this app is choosing to ignore the signal because it needs to stay running". With systemd, there is an option to reap these processes so that when you log out, you never have to worry about some misbehaving process hanging around and causing problems when you log back in. The way to fix this without disabling the feature is by explicitly putting the process in it's own scope. That doesn't take special permissions to do, it's just that it needs to be done explicitly instead of just ignoring SIGHUP.

vacri 10y ago

I've written a few unit files, including some edge cases like binding one service to another, and it's just a few more key/value pairs. This being said, upstart has a similarly simple setup. Any time I have to fiddle with sysv init files, I long for either of upstart or systemd.