10 ms·

I expect an init system to be an init system, not to also be pm-utils, (x)inetd, acpid, syslogd, watchdog, cron and atd. I also expect it to have configuration

I expect an init system to be an init system, not to also be pm-utils, (x)inetd, acpid, syslogd, watchdog, cron and atd. I also expect it to have configuration files I can change, not to have everything symlinked to /usr. (If I can even find the right configuration file in that mess of directories, that is.)

antihero 13y ago
It's quite trivial to override services - you just cp /usr/lib/systemd/system/myservice to /etc/systemd/system/myservice and edit it there. This has the advantage of not having you screw up the actual package managed files, too.
- rodgerd 13y ago
  No, you don't copy it! Source it ( . /usr/lib/systemd/system/myservice at the head of /etc/systemd/system/myservice ) then override the lines you want to change. Much easier for upgrades.
  - antihero 13y ago
    Neat! Thanks for that.
Elhana 13y ago
If Lennart Poettering were building a bicycle, it would have multiple seats, 4 wheels, engine, conditioner, bar, sat tv, console and small pool on it. You would be able to remove most of it tho... maybe. If you try to remove the engine, it would complain that modern all bicycles are broken without engines, but you can do it at your own risk.
- bkor 13y ago
  Your comparison makes no sense at all. E.g. systemd dependencies are minimal. My take: if he builds a bicycle it would be lean, fast and he'd analyse all existing designs to make that happen.
  - Sssnake 13y ago
    What do dependencies have to do with anything? If I make a huge massive bloated mess of shit, it isn't suddenly "lean" because I included everything in it rather than linking to it as a dependency.
    - bkor 13y ago
      I suggest investigating systemd then. It isn't bloated. See for instance http://people.debian.org/~stapelberg/2013/06/09/systemd-bloat.html http://people.debian.org/~stapelberg/2013/06/09/systemd-bloa.... There are a lot of different parts to it. Note the time of the blog. Saying systemd is bloated is IMO so 2013 :P
      - asdasf 13y ago
        It is bloated. Saying "I am cool with how bloated it is" does not change that.
- deleted 13y ago
  [deleted]
hkhanna 13y ago
The parent comment captures why systemd makes me uneasy, and why I moved from Arch to Debian when I noticed Arch had replaced init with systemd. The Art of Unix Programming (the book) suggests that software should do one thing and do it well, with easy, plain-text interfaces to its input and output. Systemd tries to do everything -- replacing by default so many core system components like syslog and cron. But what really bothered me was when I realized that systemd stores all the system logfiles in binary by default! I couldn't believe it. All the system log files: boot, kern, messages, whatever, were stored in some binary format. At that point, rather than research how this new binary log file was implemented, I abandoned Arch and systemd for the init system that had served me well for 15 years. Log files don't need to be in binary. It means we can't use our standard tools: cut, sort, grep, awk, etc. It means we can't use scripts we have written built on those tools we may have built over decades of working with UNIX. I guess my point is, systemd, by storing things in binary format and by trying to be the 'everything' daemon, violates two core UNIX programming philosophies: use plain-text interfaces & do one thing well.
- danudey 13y ago
  Log files being in binary lets you do things like filter based on specific fields rather than on more complicated string matching. For example, you can get log file messages from postfix's smtp process (as opposed to its smtpd process) with one command (journalctl /usr/lib/postfix/smtp), which you can then cut/sort/grep/awk/etc. You can also follow the logs with journalctl -f and go from there as well. The problem that this solves is the classic 'what log file does this daemon log this error level to on this system', which varies a surprising amount between daemons, versions, distributions, etc. I don't actually care which log file I look at, I just want to know what errors monit is getting. systemd and journalctl provide that handily. I would agree with an approach to have systemd send log events to e.g. journald (or syslog-ng, or whatever the user wanted) to separate that functionality out, however.
  - mixmastamyk 13y ago
    That sounds handy, but I wonder if json could provide the same thing.
spystath 13y ago
Systemd is a decent init system, fast (ssd+systemd=10 sec from button press), and dependency resolution is quite good. The units are configurable in the /etc/systemd directory and take precedence over the (/usr)/lib/systemd units. It is not perfect but it works. I believe it is somewhat better that sysvinit especially in dependencies. You just need an After=foo.service or Wants=foo.service and systemd takes care of everything. I know this is supported by sysvinit but the whole numbering thing always seemed like a hack to me. Systemd gets it right. That being said, I can't say I am a fan of the integration of other services within systemd, it seems somewhat bloated. And I certainly don't like the whole journal thing. When the journal becomes bigger it becomes considerably slower. And I don't get the point for binary logs. I mean, logs are just text, why overcomplicate things? I've been using it for over a year in Arch it is really good as an init daemon, I believe it is definitely a step to the right direction especially for desktops/workstations, probably for mobile as well. The rest of the package though, I am not so sure.
exDM69 13y ago
> I expect an init system to be an init system, not to also be pm-utils, (x)inetd, acpid, syslogd, watchdog, cron and atd. The problem with this traditional unix approach is that in addition to init, pm-utils, inetd, cron, etc you end up having thousands of lines of shell scripts that glue all this together in a big brittle mess. While this approach may be fine for servers which boot once and stay on for ages, are connected to fast wired network and are generally rather stable configurations, I don't want such a system for my desktop, laptop or mobile device. I expect modern devices to be able to deal with changes in power supply (battery/mains/low battery), connecting and disconnecting devices (storage, peripherals, audio devices, etc) and changes in network connectivity (intentional disconnection as well as network failure). This may involve starting and stopping services, mounting and unmounting partitions and taking other actions when the physical configuration changes. I also expect my computers to boot and shutdown quickly and effectively. Some of this is already doable in other systems, like the traditional Debian network setup (originally built in the era of wired networks) which can run scripts on connect/disconnect. But the situation ends up being what I described above: thousands of lines of brittle shell scripts. I welcome the changes and the effort put in systemd and other init systems. Traditional unix init just doesn't cut it any more, in particular on personal desktop and mobile devices.
- Zancarius 13y ago
  I had my reservations when Arch shifted to systemd. It seems like a tremendous break from Unix philosophy and a blatant violation of everything I knew. I'm glad they did, though. Unit files are far easier to write and having a supervisor behavior in the init system alleviates a tremendous amount of administrative overhead. That's not to say shell scripts are difficult, but they can break in mysterious ways. Though I imagine the same is true for systemd, from an end user perspective, its implementation (once you understand it) requires less effort. There are those who disagree, and I respect that. But the improvements to my desktop boot time are substantial. And writing a quick unit file to run something on boot requires little mental overhead. Just a glance over the manpage is enough to get started. sysvinit scripts on the other hand... well, maybe my memory is really poor, but if it's been more than a few months since I've written one for the specific system I'm targeting, it takes substantially longer. ;) So, it's likely I'm stupid or systemd is easier. Or both. Probably both.
chousuke 13y ago
The "systemd" project really isn't about having just an init system. systemd by itself is an init, but the project includes several other tools related to managing the system as a whole beyond just starting services. The project integrates a bunch of utilities that each accomplish something on their own. To me, it makes perfect sense for these tools to be tightly integrated, both with each other and with the OS kernel, simply because they are interrelated and integration leads to greater stability and a less fragile system overall. No doubt upstream could be less hostile towards attempts to distill out the portable bits, but I can understand their viewpoint... Systemd is ultimately about making Linux-based systems run well.
- sparkie 13y ago
  > simply because they are interrelated and integration leads to greater stability and a less fragile system overall. This is completely counter to the way we actually design software - which is to create modular, loosely coupled components, using abstractions which allow them to adapt or be replaced, and trying to make as few assumptions as we can, since we can't predict the future. It's well understood that tight coupling is what leads to fragility and maintenance nightmares, due to decades of experience writing and maintaining such abominations.
  - chousuke 13y ago
    That just sounds like an argument from idealism. Writing software is all about tradeoffs, and not supporting non-Linux systems is one tradeoff that systemd makes, for a good reason. In this case, close integration with the kernel is required to be able to produce the features envisioned. You might perhaps find some instances where systemd components are needlessly interrelated, but the claim that it isn't modular is mostly a myth.
kephra 13y ago
> not to have everything symlinked to /usr. an init system should be able to run !BEFORE! /usr is even mounted. Thats the division between /directory and /usr/directory, that /usr is mounted later.
- Shish2k 13y ago
  While that's the theory, it hasn't actually worked in practice on most distros for many years -- rather than having "core stuff in root, extra stuff in /usr", we now have "core stuff in initrd, some extra stuff in root, different extra stuff in /usr, with different distros splitting the latter two up differently", the usr merge actually brings us back to the original clean design of having one "core" place and one "extras" place
midas007 13y ago
And udev, which was folded into systemd.

antihero 13y ago

It's quite trivial to override services - you just cp /usr/lib/systemd/system/myservice to /etc/systemd/system/myservice and edit it there. This has the advantage of not having you screw up the actual package managed files, too.

rodgerd 13y ago
No, you don't copy it! Source it ( . /usr/lib/systemd/system/myservice at the head of /etc/systemd/system/myservice ) then override the lines you want to change. Much easier for upgrades.
- antihero 13y ago
  Neat! Thanks for that.

Elhana 13y ago

If Lennart Poettering were building a bicycle, it would have multiple seats, 4 wheels, engine, conditioner, bar, sat tv, console and small pool on it. You would be able to remove most of it tho... maybe. If you try to remove the engine, it would complain that modern all bicycles are broken without engines, but you can do it at your own risk.

bkor 13y ago
Your comparison makes no sense at all. E.g. systemd dependencies are minimal. My take: if he builds a bicycle it would be lean, fast and he'd analyse all existing designs to make that happen.
- Sssnake 13y ago
  What do dependencies have to do with anything? If I make a huge massive bloated mess of shit, it isn't suddenly "lean" because I included everything in it rather than linking to it as a dependency.
  - bkor 13y ago
    I suggest investigating systemd then. It isn't bloated. See for instance http://people.debian.org/~stapelberg/2013/06/09/systemd-bloat.html http://people.debian.org/~stapelberg/2013/06/09/systemd-bloa.... There are a lot of different parts to it. Note the time of the blog. Saying systemd is bloated is IMO so 2013 :P
    - asdasf 13y ago
      It is bloated. Saying "I am cool with how bloated it is" does not change that.
deleted 13y ago
[deleted]

hkhanna 13y ago

The parent comment captures why systemd makes me uneasy, and why I moved from Arch to Debian when I noticed Arch had replaced init with systemd. The Art of Unix Programming (the book) suggests that software should do one thing and do it well, with easy, plain-text interfaces to its input and output. Systemd tries to do everything -- replacing by default so many core system components like syslog and cron. But what really bothered me was when I realized that systemd stores all the system logfiles in binary by default! I couldn't believe it. All the system log files: boot, kern, messages, whatever, were stored in some binary format. At that point, rather than research how this new binary log file was implemented, I abandoned Arch and systemd for the init system that had served me well for 15 years. Log files don't need to be in binary. It means we can't use our standard tools: cut, sort, grep, awk, etc. It means we can't use scripts we have written built on those tools we may have built over decades of working with UNIX. I guess my point is, systemd, by storing things in binary format and by trying to be the 'everything' daemon, violates two core UNIX programming philosophies: use plain-text interfaces & do one thing well.

danudey 13y ago
Log files being in binary lets you do things like filter based on specific fields rather than on more complicated string matching. For example, you can get log file messages from postfix's smtp process (as opposed to its smtpd process) with one command (journalctl /usr/lib/postfix/smtp), which you can then cut/sort/grep/awk/etc. You can also follow the logs with journalctl -f and go from there as well. The problem that this solves is the classic 'what log file does this daemon log this error level to on this system', which varies a surprising amount between daemons, versions, distributions, etc. I don't actually care which log file I look at, I just want to know what errors monit is getting. systemd and journalctl provide that handily. I would agree with an approach to have systemd send log events to e.g. journald (or syslog-ng, or whatever the user wanted) to separate that functionality out, however.
- mixmastamyk 13y ago
  That sounds handy, but I wonder if json could provide the same thing.

spystath 13y ago

Systemd is a decent init system, fast (ssd+systemd=10 sec from button press), and dependency resolution is quite good. The units are configurable in the /etc/systemd directory and take precedence over the (/usr)/lib/systemd units. It is not perfect but it works. I believe it is somewhat better that sysvinit especially in dependencies. You just need an After=foo.service or Wants=foo.service and systemd takes care of everything. I know this is supported by sysvinit but the whole numbering thing always seemed like a hack to me. Systemd gets it right. That being said, I can't say I am a fan of the integration of other services within systemd, it seems somewhat bloated. And I certainly don't like the whole journal thing. When the journal becomes bigger it becomes considerably slower. And I don't get the point for binary logs. I mean, logs are just text, why overcomplicate things? I've been using it for over a year in Arch it is really good as an init daemon, I believe it is definitely a step to the right direction especially for desktops/workstations, probably for mobile as well. The rest of the package though, I am not so sure.

exDM69 13y ago

> I expect an init system to be an init system, not to also be pm-utils, (x)inetd, acpid, syslogd, watchdog, cron and atd. The problem with this traditional unix approach is that in addition to init, pm-utils, inetd, cron, etc you end up having thousands of lines of shell scripts that glue all this together in a big brittle mess. While this approach may be fine for servers which boot once and stay on for ages, are connected to fast wired network and are generally rather stable configurations, I don't want such a system for my desktop, laptop or mobile device. I expect modern devices to be able to deal with changes in power supply (battery/mains/low battery), connecting and disconnecting devices (storage, peripherals, audio devices, etc) and changes in network connectivity (intentional disconnection as well as network failure). This may involve starting and stopping services, mounting and unmounting partitions and taking other actions when the physical configuration changes. I also expect my computers to boot and shutdown quickly and effectively. Some of this is already doable in other systems, like the traditional Debian network setup (originally built in the era of wired networks) which can run scripts on connect/disconnect. But the situation ends up being what I described above: thousands of lines of brittle shell scripts. I welcome the changes and the effort put in systemd and other init systems. Traditional unix init just doesn't cut it any more, in particular on personal desktop and mobile devices.

Zancarius 13y ago
I had my reservations when Arch shifted to systemd. It seems like a tremendous break from Unix philosophy and a blatant violation of everything I knew. I'm glad they did, though. Unit files are far easier to write and having a supervisor behavior in the init system alleviates a tremendous amount of administrative overhead. That's not to say shell scripts are difficult, but they can break in mysterious ways. Though I imagine the same is true for systemd, from an end user perspective, its implementation (once you understand it) requires less effort. There are those who disagree, and I respect that. But the improvements to my desktop boot time are substantial. And writing a quick unit file to run something on boot requires little mental overhead. Just a glance over the manpage is enough to get started. sysvinit scripts on the other hand... well, maybe my memory is really poor, but if it's been more than a few months since I've written one for the specific system I'm targeting, it takes substantially longer. ;) So, it's likely I'm stupid or systemd is easier. Or both. Probably both.

chousuke 13y ago

The "systemd" project really isn't about having just an init system. systemd by itself is an init, but the project includes several other tools related to managing the system as a whole beyond just starting services. The project integrates a bunch of utilities that each accomplish something on their own. To me, it makes perfect sense for these tools to be tightly integrated, both with each other and with the OS kernel, simply because they are interrelated and integration leads to greater stability and a less fragile system overall. No doubt upstream could be less hostile towards attempts to distill out the portable bits, but I can understand their viewpoint... Systemd is ultimately about making Linux-based systems run well.

sparkie 13y ago
> simply because they are interrelated and integration leads to greater stability and a less fragile system overall. This is completely counter to the way we actually design software - which is to create modular, loosely coupled components, using abstractions which allow them to adapt or be replaced, and trying to make as few assumptions as we can, since we can't predict the future. It's well understood that tight coupling is what leads to fragility and maintenance nightmares, due to decades of experience writing and maintaining such abominations.
- chousuke 13y ago
  That just sounds like an argument from idealism. Writing software is all about tradeoffs, and not supporting non-Linux systems is one tradeoff that systemd makes, for a good reason. In this case, close integration with the kernel is required to be able to produce the features envisioned. You might perhaps find some instances where systemd components are needlessly interrelated, but the claim that it isn't modular is mostly a myth.

kephra 13y ago

> not to have everything symlinked to /usr. an init system should be able to run !BEFORE! /usr is even mounted. Thats the division between /directory and /usr/directory, that /usr is mounted later.

Shish2k 13y ago
While that's the theory, it hasn't actually worked in practice on most distros for many years -- rather than having "core stuff in root, extra stuff in /usr", we now have "core stuff in initrd, some extra stuff in root, different extra stuff in /usr, with different distros splitting the latter two up differently", the usr merge actually brings us back to the original clean design of having one "core" place and one "extras" place

midas007 13y ago

And udev, which was folded into systemd.