nixers
PEACEFUL systemd thread - Printable Version
+- nixers (https://nixers.net)
+-- Forum: Operating Systems (https://nixers.net/forumdisplay.php?fid=4)
+--- Forum: GNU/Linux (https://nixers.net/forumdisplay.php?fid=12)
+--- Thread: PEACEFUL systemd thread (/showthread.php?tid=2009)
Pages: 1 2 3


RE: PEACEFUL systemd thread - josuah - 03-11-2016

I imagined the shell was first written to manage and start the other commands of the system. But it seems that it was first for some kind of interactive use:

https://en.wikipedia.org/wiki/Unix_shell#Early_shells
http://www.multicians.org/shell.html

But even if it was not, the shell can still be considered as a monolithic C program made to boot the system by running external commands, configurable enough to cover all use cases user may encounter. It rely on external commands, and compose them.

From this point of view it looks that systemd is replacing the shell, by calling external commands (with a 'd' at the end, like "journald") and composing them to make an init system.

Is this really the shortcomings of popular shells that gave a rise to systemd?

(03-11-2016, 01:45 PM)TheAnachron Wrote: near-second kernel

Oh, overlapping with kernel features too, some sort of kernel-level shell, then?


RE: PEACEFUL systemd thread - pranomostro - 03-11-2016

(03-11-2016, 03:11 PM)josuah Wrote: Is this really the shortcomings of popular shells that gave a rise to systemd?

Interesting idea.

About integration of commands: I think the reason traditional unix enthusiasts oppose systemD is that it
does not want to integrate into the existing unix system. I have wanted to write a little blog post about
this, but in short unix is not about making another unix (which systemD may very well be), but integrating into
the existing unix by using the usual data transfer and transformation methods.


RE: PEACEFUL systemd thread - z3bra - 15-06-2017

After all this time, I managed to make my experience with systemd less "worse" than it was. At work, we start using centos 7 (irony, I'm in charge of doing that, and thus explain systemd to my colleagues), and I must say that things don't change that much (mostly because red hat worked hard so it does not).

After forcing myself to use it (on my local work machine as well), here are a few thoughs:
  • it just works ™
  • journalctl still feels painful to use so I keep logs in /var/log
  • systemd-resolved works, but I have no idea how, or why
  • systemd-networkd took me some time to understand, but it is easier to configure than plain shell scripts (good for noobs)
  • all default services work well, which is nice because...
  • editing services feel hacky, and complex. there are a shitons of variable and files that can change how a service behaves

So overall, yeah, systemd works, and you will not notice it most of the time. You will have to learn a new system infrastructure though, that is, IMO, not well though or standardized (Even if you know how service configuration is done, you will still have to learn how networkd is configured, or resolved...)

I think systemd is growing to fast to polish all ots rough edges, and even if it will grow stable enough to, one day, be the single dependency to build a fully fledged distro, it will be hard to manage.

Free the init!


RE: PEACEFUL systemd thread - azk - 15-06-2017

(15-06-2017, 06:16 AM)z3bra Wrote:
  • editing services feel hacky, and complex. there are a shitons of variable and files that can change how a service behaves

I'd argue that it's just different. I had the pleasure of showing someone fairly new to FreeBSD how to write a service file and that is just as hacky and full of arbitrary variables.
The only thing I really don't like writing is systemd timers. I just want my cron back :(


RE: PEACEFUL systemd thread - evbo - 15-06-2017

While I avoid systemd as much as possible, I will agree that it "Just Works" for basic operations. Hell, for a workstation distro it's probably the easiest choice as most of the time you don't have to touch anything.

The problems I have are usually server-level, with things like systemd-resolved and those awful binary logs. Though I'm slowly moving my servers and personal apps to OpenBSD or Docker containers, I still use CentOS for a few things. I'll admit that for me it's an ideological thing. Since my professional experience is in the Windows enterprise (kill me), I know the evils of bloated, all-encompassing systems. Systemd's progress of eating all the things (resolve, cron, mounting, etc) is bad for the Linux environment.


RE: PEACEFUL systemd thread - z3bra - 15-06-2017

I also work with windows based machines and am fully satisfied with it, but I digress (that could deserve a topic on its own).

To first answer azk, I consider freebsd, openbsd ans sysv to be too complex as well, as there is too much abstraction between what you write and what is actually done. I'd head more toward things like runit or daemontools, where you can guess how to configure things on your own, without bothering about how it works internally.
When you got the following arborescence:
Code:
/services
/services/httpd
/services/httpd/run
/services/sshd
/services/sshd/run
/services/sshd/onboot

It's easy to understand how to create a new service, as the content of "run" is simply
Code:
sshd -D -f /etc/ssh/sshd_config

easier than anything else really. No complex variable, no surprise on what will run, no hidden framework to source... Just a shell script, that you can run on its own to test it


RE: PEACEFUL systemd thread - venam - 15-06-2017

(15-06-2017, 02:35 PM)z3bra Wrote: easier than anything else really. No complex variable, no surprise on what will run, no hidden framework to source... Just a shell script, that you can run on its own to test it

However there are two things you are missing:
  • The role of an init system is not limited to the role of a service manager, it's only one feature amongst others it can provide.
  • The role of a service manager is not limited to simply starting the services it might also do the following:
    • Start daemons (whole detachment process)
    • Have some sort of order, be it synchronous and deterministic, or asynchronous dependency based, plus:
      • could be according to a simple list
      • could be according to some dynamic factors/events (socket, devices connected, new mount point, time based(periodic), file system changes, etc..)
    • Control and monitor the daemons (centralized way to do that)
    • Recover in case of crashes
    • Provide debug logs (dumps, traces) in case of crash
    • It could have a centralized log mechanism
    • Integrate some sort of IPC



RE: PEACEFUL systemd thread - z3bra - 15-06-2017

(15-06-2017, 02:49 PM)venam Wrote:
(15-06-2017, 02:35 PM)z3bra Wrote: easier than anything else really. No complex variable, no surprise on what will run, no hidden framework to source... Just a shell script, that you can run on its own to test it

However there are two things you are missing:
  • The role of an init system is not limited to the role of a service manager, it's only one feature amongst others it can provide.
  • The role of a service manager is not limited to simply starting the services it might also do the following:
    • Start daemons (whole detachment process)
    • Have some sort of order, be it synchronous and deterministic, or asynchronous dependency based, plus:
      • could be according to a simple list
      • could be according to some dynamic factors/events (socket, devices connected, new mount point, time based(periodic), file system changes, etc..)
    • Control and monitor the daemons (centralized way to do that)
    • Recover in case of crashes
    • Provide debug logs (dumps, traces) in case of crash
    • It could have a centralized log mechanism
    • Integrate some sort of IPC

The init systems I mentioned are indeed not perfect (none of them is actually, which is why we're facing a war of inits).
First of all, I don't think it's the init job to handle services. Its role is to bring up the system. What happens next is irrelevant to the "init".
For services, you're right, today, only systemd can start a service when a special path is mounted, or a socket is created. But is it the right way to do it? In the end, is a mount point semantically different from a "network" service? IMO, they should all be treaten the same, using a mechanism similar to the need(8) idea (see https://web.archive.org/web/20010428121148/http://www.atnf.csiro.au:80/~rgooch/linux/boot-scripts)

basically, your script could be this (note that mpd flags are random here, I don't know.them):
Code:
need network
need music.nfs
mpd --foreground --musicdir /mount/nfs/music



RE: PEACEFUL systemd thread - venam - 15-06-2017

(15-06-2017, 03:36 PM)z3bra Wrote: First of all, I don't think it's the init job to handle services. Its role is to bring up the system. What happens next is irrelevant to the "init".
And this is where the controversy is, there's no clear definition of the limits of the bootstraping process, the edges are hazy.
You could have an init system that just barely gets you runing by giving you a tty or you could have an init system that practically toss you in a graphical environment all ready to go. The edges of the *initialization* are not clear all of that is based on personal opinions.

Also, having the PID 1 makes it easier to handle services.


RE: PEACEFUL systemd thread - z3bra - 15-06-2017

Quote:having the PID 1 makes it easier to handle services.

I disagree with you there. It is only said so because orphaned programs get adopted by PID 1. Proper service handling can be done by any process, as long as their children don't double fork themselves (which they shouldn't do on their own anyway).