6 ms·

Everything I know about systemd is bad. When I want to write a script that runs on startup, I expect that I can just put (or link) it in some directory where t

by doiwin 7y ago

Everything I know about systemd is bad. When I want to write a script that runs on startup, I expect that I can just put (or link) it in some directory where the scripts are that get started on startup. Or that there is one main script that calls all scripts that are intended to be startet on startup. I do not want to write a "service" that has some "only run once and then discard" flag or whatever. When I want to look at logs, I want to use the tools I like. less, grep, tail etc. I do not want to dabble with some binary format and its tooling. When I want to start or stop a service, I want to call a script that does that. A script which I can look at and see what it does. Like /etc/init.d/apache2. I do not want to execute some magic command like "service apache start" which I have to guess or look up and which gives me no clue about what it does.

eythian 7y ago
That's just saying "I want things to be the way I first learnt them and don't want them to change." This is fine, but you do have to accept that things are going to move on without you.
- doiwin 7y ago
  By that logic, no mistakes can ever be criticized. I explained, why systemd is a step in the wrong direction in mutiple ways. That has nothing to do with habbits.
  - Shish2k 7y ago
    > I explained, why systemd is a step in the wrong direction I see a bunch of "I want X", but I don't see any "why"
    - madez 7y ago
      But there have been reasons given. They want to use standard tools to deal with the log. They want to see the scripts that manage the system and poke around in it, which has the implicit reason to learn about the system and being able to easily modify it.
      - madhadron 7y ago
        > They want to use standard tools to deal with the log. I have a little sympathy for this one as an old habit if you don't know any better. It's also an extremely inefficient way to work with logs. If you've used a system like Splunk seriously, the idea of going back and grepping through logs on a host with the shell is just frustrating. > They want to see the scripts that manage the system and poke around in it, which has the implicit reason to learn about the system and being able to easily modify it. I have no sympathy for this one. Scripts are a terrible place to define policy. They are nigh impossible to audit. They are brittle. They multiply complexity by making everything a special case. They make integration of different parts of the system nearly impossible.
    - syrrim 7y ago
      >I want to use the tools I like >I want to call a script that does that. A script which I can look at and see what it does
- segmondy 7y ago
  No, that's saying I want things that stick to the Unix philosophy of simplicity, clarity and text formats with no hidden magic.
  - cesarb 7y ago
    Aren't systemd units simple text files with no hidden magic? In fact, all systemd configuration is plain text files and symbolic links. The only binary format is the journal.
    - csande17 7y ago
      > Aren't systemd units simple text files with no hidden magic? Compared to something like a shell script, systemd unit files are magic because you have to know a lot about how systemd works to figure out how your config file translates into actual behavior.
      - eythian 7y ago
        I think learning systemd configs is substantially easier than learning an entire awkward programming language.
- tempguy9999 7y ago
  Whenever systemd comes up, someone appears to counter any criticism with words suggesting you'll get left behind if you don't follow us. No justification beyond that.
- giancarlostoro 7y ago
  Heck I hadnt used Linux for a few years and when I got back to it systemd was on every distro I use. I just use it. I dont see the big deal. I grep the piped output of services if I want to narrow things down more just as you would the output of cat or ls or anything on Linux.
Znafon 7y ago
> When I want to write a script that runs on startup, I expect that I can just put (or link) it in some directory where the scripts are that get started on startup This is not very specific, have you never had any race-condition with this? There is a reason SystemD ask some informations regarding the service that needs to be launched. I don't see how ignoring those makes a good argument against SystemD.
- doiwin 7y ago
  No, I can not remember having a race condition regarding startup scripts.
  - izacus 7y ago
    Then you didn't have to mantain a system of any kind of complexity.
    - tempguy9999 7y ago
      And you have? Can you give an example and how you solved it? Thanks! (edit: not trolling; curious)
      - Znafon 7y ago
        I think my issue what binding Consul to docker0 while Docker is starting. Half the time the interface wasn't ready. I don't remember exactly how I fixed it but with SystemD you can just specify a dependency.
  - Znafon 7y ago
    I think I had one where one service was trying to bind to a network interface that wasn't ready, maybe docker0. It was painful to find and fix.
- labawi 7y ago
  Many simple systems don't do parallel service startup like systemd, if that is what you mean.
darpa_escapee 7y ago
> I do not want to write a "service" that has some "only run once and then discard" flag or whatever. Then just use cron.
madhadron 7y ago
> A script which I can look at and see what it does. Like /etc/init.d/apache2. I do not want to execute some magic command like "service apache start" which I have to guess or look up and which gives me no clue about what it does. Interesting. I feel the other way. Unix failed to provide a real service management system early on, so we have layers of historical cruft (Fork, close all descriptors, fork again, escape process group? Really?), and ended up with all kinds of absurdity in shell scripts to handle it. The right way is to have a strong system contract on what constitutes a service, and have no wiggle room so that 'service apache start' does a fixed, known thing. Sadly, systemd has to support all kinds of legacy hacks. A nice way to chart a way forward might be to define a simple contract and require someone to mark a unit file as "legacy" to enable the other possibilities.
soraminazuki 7y ago
> When I want to write a script that runs on startup, I expect that I can just put (or link) it in some directory where the scripts are that get started on startup. Or that there is one main script that calls all scripts that are intended to be startet on startup. AFAIK, systemd is compatible with sysv init scripts. > I do not want to write a "service" that has some "only run once and then discard" flag or whatever. Why? Writing one isn't so complicated. > When I want to look at logs, I want to use the tools I like. less, grep, tail etc. I do not want to dabble with some binary format and its tooling. Well, nothing prevents you from piping output from journalctl to whichever tool you prefer. In fact, people do it all the time. > When I want to start or stop a service, I want to call a script that does that. A script which I can look at and see what it does. Like /etc/init.d/apache2. I do not want to execute some magic command like "service apache start" which I have to guess or look up and which gives me no clue about what it does. I don't see how sysv init is any better than systemd in this regard. You'd still have to look at indidual scripts to see what it does. It's not like systemd hides the contents of the service files.
XorNot 7y ago
So I take it you've never used journalctl then at all? Because seeing as how it's default behaviour is to use the system pager, which on any system with `less` installed is less, I'm somewhat at a loss as to what you can't do with it that you can with files now.

by doiwin 7y ago

eythian 7y ago

That's just saying "I want things to be the way I first learnt them and don't want them to change." This is fine, but you do have to accept that things are going to move on without you.

doiwin 7y ago
By that logic, no mistakes can ever be criticized. I explained, why systemd is a step in the wrong direction in mutiple ways. That has nothing to do with habbits.
- Shish2k 7y ago
  > I explained, why systemd is a step in the wrong direction I see a bunch of "I want X", but I don't see any "why"
  - madez 7y ago
    But there have been reasons given. They want to use standard tools to deal with the log. They want to see the scripts that manage the system and poke around in it, which has the implicit reason to learn about the system and being able to easily modify it.
    - madhadron 7y ago
      > They want to use standard tools to deal with the log. I have a little sympathy for this one as an old habit if you don't know any better. It's also an extremely inefficient way to work with logs. If you've used a system like Splunk seriously, the idea of going back and grepping through logs on a host with the shell is just frustrating. > They want to see the scripts that manage the system and poke around in it, which has the implicit reason to learn about the system and being able to easily modify it. I have no sympathy for this one. Scripts are a terrible place to define policy. They are nigh impossible to audit. They are brittle. They multiply complexity by making everything a special case. They make integration of different parts of the system nearly impossible.
  - syrrim 7y ago
    >I want to use the tools I like >I want to call a script that does that. A script which I can look at and see what it does
segmondy 7y ago
No, that's saying I want things that stick to the Unix philosophy of simplicity, clarity and text formats with no hidden magic.
- cesarb 7y ago
  Aren't systemd units simple text files with no hidden magic? In fact, all systemd configuration is plain text files and symbolic links. The only binary format is the journal.
  - csande17 7y ago
    > Aren't systemd units simple text files with no hidden magic? Compared to something like a shell script, systemd unit files are magic because you have to know a lot about how systemd works to figure out how your config file translates into actual behavior.
    - eythian 7y ago
      I think learning systemd configs is substantially easier than learning an entire awkward programming language.
tempguy9999 7y ago
Whenever systemd comes up, someone appears to counter any criticism with words suggesting you'll get left behind if you don't follow us. No justification beyond that.
giancarlostoro 7y ago
Heck I hadnt used Linux for a few years and when I got back to it systemd was on every distro I use. I just use it. I dont see the big deal. I grep the piped output of services if I want to narrow things down more just as you would the output of cat or ls or anything on Linux.

Znafon 7y ago

> When I want to write a script that runs on startup, I expect that I can just put (or link) it in some directory where the scripts are that get started on startup This is not very specific, have you never had any race-condition with this? There is a reason SystemD ask some informations regarding the service that needs to be launched. I don't see how ignoring those makes a good argument against SystemD.

doiwin 7y ago
No, I can not remember having a race condition regarding startup scripts.
- izacus 7y ago
  Then you didn't have to mantain a system of any kind of complexity.
  - tempguy9999 7y ago
    And you have? Can you give an example and how you solved it? Thanks! (edit: not trolling; curious)
    - Znafon 7y ago
      I think my issue what binding Consul to docker0 while Docker is starting. Half the time the interface wasn't ready. I don't remember exactly how I fixed it but with SystemD you can just specify a dependency.
- Znafon 7y ago
  I think I had one where one service was trying to bind to a network interface that wasn't ready, maybe docker0. It was painful to find and fix.
labawi 7y ago
Many simple systems don't do parallel service startup like systemd, if that is what you mean.

darpa_escapee 7y ago

> I do not want to write a "service" that has some "only run once and then discard" flag or whatever. Then just use cron.

madhadron 7y ago

> A script which I can look at and see what it does. Like /etc/init.d/apache2. I do not want to execute some magic command like "service apache start" which I have to guess or look up and which gives me no clue about what it does. Interesting. I feel the other way. Unix failed to provide a real service management system early on, so we have layers of historical cruft (Fork, close all descriptors, fork again, escape process group? Really?), and ended up with all kinds of absurdity in shell scripts to handle it. The right way is to have a strong system contract on what constitutes a service, and have no wiggle room so that 'service apache start' does a fixed, known thing. Sadly, systemd has to support all kinds of legacy hacks. A nice way to chart a way forward might be to define a simple contract and require someone to mark a unit file as "legacy" to enable the other possibilities.

soraminazuki 7y ago

> When I want to write a script that runs on startup, I expect that I can just put (or link) it in some directory where the scripts are that get started on startup. Or that there is one main script that calls all scripts that are intended to be startet on startup. AFAIK, systemd is compatible with sysv init scripts. > I do not want to write a "service" that has some "only run once and then discard" flag or whatever. Why? Writing one isn't so complicated. > When I want to look at logs, I want to use the tools I like. less, grep, tail etc. I do not want to dabble with some binary format and its tooling. Well, nothing prevents you from piping output from journalctl to whichever tool you prefer. In fact, people do it all the time. > When I want to start or stop a service, I want to call a script that does that. A script which I can look at and see what it does. Like /etc/init.d/apache2. I do not want to execute some magic command like "service apache start" which I have to guess or look up and which gives me no clue about what it does. I don't see how sysv init is any better than systemd in this regard. You'd still have to look at indidual scripts to see what it does. It's not like systemd hides the contents of the service files.

XorNot 7y ago

So I take it you've never used journalctl then at all? Because seeing as how it's default behaviour is to use the system pager, which on any system with `less` installed is less, I'm somewhat at a loss as to what you can't do with it that you can with files now.