6 ms·

Surely you enjoy the irony of the move to microservices and isolation when merging so many functions into init ?

by geggam 8y ago

theamk 8y ago
I am not sure what you are getting at. "systemd" deb package does contain lots of binaries, 73 in my case: dpkg -L systemd | xargs stat -c '%F %A %n' | grep file.*rwx | wc -l 73 Each binary does one thing. So for example /lib/systemd/systemd, the PID 1 process, only starts processes, nothing else. Now, some people complain that "systemd" package contain other binaries, like systemd-networkd, or systemd-journal-gatewayd (the HTTP server). I don't understand their problems. Sure, it is annoying that "systemd" package contains network manager -- but you don't have to use it; in fact, I am not using it at all. So I do not see the irony. I think 73 binaries, each optional, easily replaceable, and doing only one thing, is very much inline to microservices philosophy.
- rleigh 8y ago
  The number of binaries isn't in and of itself a good measure. It says nothing about the tight coupling and poorly documented interfaces which tie them all together. There are two major things to consider here: - how easy is it to replace each of these with an independent third-party implementation - if it is possible, why should the design of that component be dictated by the systemd upstream A huge amount of the value of Linux was the fact that the system was a loosely-coupled collection of parts. Much of that flexibility has been lost, and with it the utility which drove a lot of the adoption of Linux in the first place.
  - theamk 8y ago
    Re "how easy is it to replace each of these with an independent third-party implementation" What did you have in mind when you were talking about hard-to-replace implementation? I find the replacing all those components to be pretty easy. Those things are all loaded via regular unit files, and they need just one symlink to be completely disabled. In particular, systemd-networkd is entirely optional, and ifupdown is still supported in ubuntu (even if not installed by default). systemd-timesyncd is a regular service, and can be disabled directly, or via timedatectl. ntpdate still works when it is disabled. Many other services, like systemd-hostnamed, do not even run by default. You could disabled them by default and things would still work. The worst offender is probably systemd-logind, but luckily I did not have to deal with it. Looks like it only needed for GUI logins, not ssh one -- so most sysadmins would not have to care. That said, I did try to use it's predecessor, ConsoleKit, and it was pretty horrible as well.
- geggam 8y ago
  The decoupling of services is the trend of microservices. Systemd is merging many previously decoupled systems to manage them and provide a platform for decoupled services. Seems ironic to me is all
  - theamk 8y ago
    For me, "decoupling" means running separate processes with well-defined interfaces. Systemd does exactly that -- it has many separate processes, each with well-defined interfaces. For example, systemd-timesyncd can be run on any machine with dbus, and does not require systemd init at all. The only "merging" systemd does is that it puts multiple binaries into one package, other than that they are completely separate. While it is annoying waste of space, there is no reason to suspect "coupling".
    - geggam 8y ago
      Your idea of well defined and mine are somewhat different :)
      - theamk 8y ago
        Can you be more specific, please? Like which interface is not well defined? I find the fact that systemd internals are connected via the same mechanisms as non-systemd apps (units, sockets and so on) very nice, especially compared to sysvinit or upstart. Have you tried to patch network detection in upstart? Not an easy job. And upstart's manpages are less than useful, compared to systemd's. Above in the other threads someone said "journal". This is a good point, except there is --log-target=kmsg option which disables that interface and switches it to good old kmsg which anyone can parse and read. Any others?
- zbentley 8y ago
  > 73 binaries, each optional, easily replaceable. Except for the journal. It is effectively required by systemd (the pid 1 binary). In the vast majority of cases, that means running systemd-journald. Every attempt I have seen at operating without it either misses early logs or is extremely fragile/unsupported. That's a point of fact, not a position in the larger argument here. There are good arguments as to why journald should be effectively a required component. > /lib/systemd/systemd, the PID 1 process, only starts processes, nothing else. That is incorrect. It also interacts with the journal, the component implicated in the exploit in the article.
  - theamk 8y ago
    > Except for the journal. It is effectively required by systemd (the pid 1 binary). In the vast majority of cases, that means running systemd-journald. man systemd ... --log-target= Set log target. Argument must be one of console, journal, kmsg, journal-or-kmsg, null. you can log to kmsg -- the messages won't be lost. > Every attempt I have seen at operating without it either misses early logs or is extremely fragile/unsupported. I am not surprised -- this was one of many annoying parts of sysvinit, the missing early userspace logs. This was one of the many annoying parts. Gentoo used to have a hacky way that scraped screen buffer (!) but I think it broke at some point[1]. > That is incorrect. It also interacts with the journal, the component implicated in the exploit in the article. Fair enough, I oversimplified. It also interacts with udev, systemctl, and does cronjob handling and network interface renaming. [1] I just checked Gentoo's website now and looks like they have a better way now due to OpenRC.

Surely you enjoy the irony of the move to microservices and isolation when merging so many functions into init ?

by geggam 8y ago

Surely you enjoy the irony of the move to microservices and isolation when merging so many functions into init ?

I am not sure what you are getting at. "systemd" deb package does contain lots of binaries, 73 in my case: dpkg -L systemd | xargs stat -c '%F %A %n' | grep file.*rwx | wc -l 73 Each binary does one thing. So for example /lib/systemd/systemd, the PID 1 process, only starts processes, nothing else. Now, some people complain that "systemd" package contain other binaries, like systemd-networkd, or systemd-journal-gatewayd (the HTTP server). I don't understand their problems. Sure, it is annoying that "systemd" package contains network manager -- but you don't have to use it; in fact, I am not using it at all. So I do not see the irony. I think 73 binaries, each optional, easily replaceable, and doing only one thing, is very much inline to microservices philosophy.

rleigh 8y ago
The number of binaries isn't in and of itself a good measure. It says nothing about the tight coupling and poorly documented interfaces which tie them all together. There are two major things to consider here: - how easy is it to replace each of these with an independent third-party implementation - if it is possible, why should the design of that component be dictated by the systemd upstream A huge amount of the value of Linux was the fact that the system was a loosely-coupled collection of parts. Much of that flexibility has been lost, and with it the utility which drove a lot of the adoption of Linux in the first place.
- theamk 8y ago
  Re "how easy is it to replace each of these with an independent third-party implementation" What did you have in mind when you were talking about hard-to-replace implementation? I find the replacing all those components to be pretty easy. Those things are all loaded via regular unit files, and they need just one symlink to be completely disabled. In particular, systemd-networkd is entirely optional, and ifupdown is still supported in ubuntu (even if not installed by default). systemd-timesyncd is a regular service, and can be disabled directly, or via timedatectl. ntpdate still works when it is disabled. Many other services, like systemd-hostnamed, do not even run by default. You could disabled them by default and things would still work. The worst offender is probably systemd-logind, but luckily I did not have to deal with it. Looks like it only needed for GUI logins, not ssh one -- so most sysadmins would not have to care. That said, I did try to use it's predecessor, ConsoleKit, and it was pretty horrible as well.
geggam 8y ago
The decoupling of services is the trend of microservices. Systemd is merging many previously decoupled systems to manage them and provide a platform for decoupled services. Seems ironic to me is all
- theamk 8y ago
  For me, "decoupling" means running separate processes with well-defined interfaces. Systemd does exactly that -- it has many separate processes, each with well-defined interfaces. For example, systemd-timesyncd can be run on any machine with dbus, and does not require systemd init at all. The only "merging" systemd does is that it puts multiple binaries into one package, other than that they are completely separate. While it is annoying waste of space, there is no reason to suspect "coupling".
  - geggam 8y ago
    Your idea of well defined and mine are somewhat different :)
    - theamk 8y ago
      Can you be more specific, please? Like which interface is not well defined? I find the fact that systemd internals are connected via the same mechanisms as non-systemd apps (units, sockets and so on) very nice, especially compared to sysvinit or upstart. Have you tried to patch network detection in upstart? Not an easy job. And upstart's manpages are less than useful, compared to systemd's. Above in the other threads someone said "journal". This is a good point, except there is --log-target=kmsg option which disables that interface and switches it to good old kmsg which anyone can parse and read. Any others?
zbentley 8y ago
> 73 binaries, each optional, easily replaceable. Except for the journal. It is effectively required by systemd (the pid 1 binary). In the vast majority of cases, that means running systemd-journald. Every attempt I have seen at operating without it either misses early logs or is extremely fragile/unsupported. That's a point of fact, not a position in the larger argument here. There are good arguments as to why journald should be effectively a required component. > /lib/systemd/systemd, the PID 1 process, only starts processes, nothing else. That is incorrect. It also interacts with the journal, the component implicated in the exploit in the article.
- theamk 8y ago
  > Except for the journal. It is effectively required by systemd (the pid 1 binary). In the vast majority of cases, that means running systemd-journald. man systemd ... --log-target= Set log target. Argument must be one of console, journal, kmsg, journal-or-kmsg, null. you can log to kmsg -- the messages won't be lost. > Every attempt I have seen at operating without it either misses early logs or is extremely fragile/unsupported. I am not surprised -- this was one of many annoying parts of sysvinit, the missing early userspace logs. This was one of the many annoying parts. Gentoo used to have a hacky way that scraped screen buffer (!) but I think it broke at some point[1]. > That is incorrect. It also interacts with the journal, the component implicated in the exploit in the article. Fair enough, I oversimplified. It also interacts with udev, systemctl, and does cronjob handling and network interface renaming. [1] I just checked Gentoo's website now and looks like they have a better way now due to OpenRC.