Announcement

Collapse
No announcement yet.

Systemd In Ten Years Has Redefined The Linux Landscape

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
    k1e0x
    Senior Member

  • k1e0x
    replied
    Originally posted by oiaohm View Post

    The timeline is not 100 percent pro systemd. It what has got us where are are now. Please go back and read carefully. Its not a strawman arguement the problem has been visible for quite some time.



    OpenRC is not complete yet in it cgroups around services or its usage of pidfd to make sure it kills the right process. Its close but not ready.



    You are wanting to make something to test out a subsystems in a kernel to make sure they work. What systemd has done is ideal for this. This is what gives us the proper foundation today to build on top of. We would not have stable cgroup v2 today without systemd giving it a heavy work out. Will we always need systemd going forwards maybe no. But we need that event to happen.




    Yes I do like Redox they have real policy that everything is a file and mean it. This include process interfacing. So Redox comes out box with pidfd equal that is important. Lot of Unix and Unix like lake the means to use a handle to interface with a process instead you only have PID that can have race condition ie your application is attempting to send kill to PID 100 but what happens at PID100 is it crashs and the OS reuses PID100 for some other process now you send kill signal to completely wrong process. https://lwn.net/Articles/794707/ Also Redox has namespaces design fairly close to cgroup v2. So Redox is on the right track to a proper good OS.

    But its going to be if Redox gets the hardware support.

    Linux kernel is on path to a proper good OS kernel by being dragged kicking and screaming in that direction.


    You don't have equals pidfd or cgroups on OS X. So launchd is fairly much screwed from providing stability as well.

    Basically there is a list functionality you need to make good service management.

    1) You must be able to kill the right process no matter what happens and must fail correctly if that process is already dead when you send signal(no kill any other process that has got the same process id number). This means you must have some solution so you can use a handle to a process that you can use to identify that is the correct process and send a kill signal to it. PID number is not this. pidfd is or like Windows process handles. Linux kernel only gets this year. OS X does not have this. Most Unixs don't have this. Redox does have this. Freebsd does have a different means of doing it as well

    2) You must be able to tell what processes were started by a service. cgroup give this under Linux. namespacing under Redox gives this as well. You don't have this under Windows or OS X properly yet. Windows developers are working on sandboxing stuff to give them this in time..

    3) Your Service management system has to take advantage of this stuff. This is why Openrc is not ready yet.

    4) You need service logging that cannot be lied to.

    5) you need service watchdog so key services can be detected as failed when they have not in fact crashed.



    This is wrong about 25% of systemd is what you need for properly managed services. The 5% roughly of what systemd does is what Openrc does is right . Problem here is your idea that 5% of systemd is required todo what it should do is wrong. Openrc is still lacking lot of the cgroup support and proper protection to prevent log faking and is still missing the pidfd stuff and finally where is your service watchdog. Fix all this up and Openrc could be one good competitor.

    So 5% claim against systemd of what it should to is wrong. Please note I am not saying that systemd is not doing too much. 75% of systemd could go away no problems. Openrc is not quite doing enough yet. Openrc does have the foundations that it could be good in time with enough investment in development to close that feature gap.

    There is no point getting these claims wrong because it only means you don't see the work that needs doing.
    This is a good post!

    (% talk is all a joke, thought it was ovis)

    Yes. I agree with a lot of that. I think Linux cgroups and namespace is part of the problem. That needs to be re-engineered honestly a lot more like Solaris Zones (something that is the model for Redox) and true process isolation and containerization. FreeBSD has jails and separate PID's in them, that is a better model, but it's not quite as robust as Zones. (still much more so than cgroups and namespace though) - Linux is kind of working with a cobbled together solution to provide this when they need to go back to the drawing board and get it right in the first place. They are building on top of a wobbly foundation.. again.. as usual. It's really a shame they are trying to fix this stuff with systemd upstack instead of solving the hard problems.

    Determining if a pid has gone down, needs to go down, or has been reused is a much larger topic and a philosophical one. I find I'm often of the opinion that if a process dies it should not be restarted, it should core dump and be investigated to find out why it went down and fixed as it isn't operating as intended and therefore needs a fix. Restarting it is very "windows sysadmin esque" and that bothers me a lot that Linux seems to think this is ok. That's a major point of contention I have with systemd and Linux in general. - There are some things where this behaviour is ok, necessary and good.. but those are edge cases and should not be the norm.. In my opinion.

    One of those edge cases might be automotive.. yes, you want the service to restart.. but would you want this restarting behaviour to be occurring all the time in your car or your airplane or would you want the software to be well tested so it does not restart at all? Making it the norm makes failing services the norm and I don't want to be on a plane with failing services. Outside of that in server space we have HA practices that generally make the need unnecessary.

    It feels to me a lot of this stuff is coming out of the Desktop Linux department, where that behaviour is more ok. I have a problem with that.. Linux is a server OS primarily. Just like FreeBSD and Solaris. Sorry if thats not OK with some people and you want "the year of the Linux/*nix desktop" (really that is macOS anyhow) .. I run FreeBSD on the desktop. Do I expect it to not act like a server? no.. I'm on my own.. and that is something I expect.

    I think the moral of this story is OS development and improvement still has a long way to come.
    k1e0x
    Senior Member
    Last edited by k1e0x; 20 December 2019, 08:39 PM.

    Leave a comment:

  • Paul Frederick
    Phoronix Member

  • Paul Frederick
    replied
    Originally posted by oiaohm View Post

    Get the point already. You don't mention the Desktop Environment that had problem by name maybe cause if you did we would know that you were fibbing. You could not type the Systemd name right. You make a non fact claim about memory usage.

    Basically what was in your post that was possible right. Basically it was a underhanded comment that you basically posted random garbage that most appears to be complete fiction written by someone who really knows nothing and has never used linux because they are just some paid troll to cause trouble.
    What difference does it make what DE I was using? It was the DE I was using. How about you be more wrong.

    Leave a comment:

  • oiaohm
    Senior Member

  • oiaohm
    replied
    Originally posted by Paul Frederick View Post
    Where did you pull your words out of? Wait, don't tell me!
    Get the point already. You don't mention the Desktop Environment that had problem by name maybe cause if you did we would know that you were fibbing. You could not type the Systemd name right. You make a non fact claim about memory usage.

    Basically what was in your post that was possible right. Basically it was a underhanded comment that you basically posted random garbage that most appears to be complete fiction written by someone who really knows nothing and has never used linux because they are just some paid troll to cause trouble.

    Leave a comment:

  • Paul Frederick
    Phoronix Member

  • Paul Frederick
    replied
    Originally posted by Britoid View Post

    Did you go into a dictionary and pull out random words?
    Where did you pull your words out of? Wait, don't tell me!

    Leave a comment:

  • F.Ultra
    Senior Member

  • F.Ultra
    replied
    Originally posted by skeevy420 View Post

    Really? Here's my generic template.

    It's this easy:

    Code:
    [Unit]
    Description=A description
    
    [Service]
    Type=oneshot
    ExecStart=/path/to/something
    RemainAfterExit=yes
    
    [Install]
    WantedBy=multi-user.target
    1. name that "foobar.service"
    2. copy "foobar.service" to "/etc/systemd/system/foobar.service"
    3. give it 644 permissions
    4. treat it like any other systemd service; "sudo systemctl start foobar.service" to run once; "sudo systemctl enable foobar.service" to start on boot; etc)
    Use Goolge or your search engine of choice to look up more advanced information, but that template works just fine to load up simple scripts on boot. Here's an actual one of mine for a working example (w/o the script it uses because you can generate your own with WattmanGTK).

    Code:
    [Unit]
    Description=Apply WattmanGTK settings
    
    [Service]
    Type=oneshot
    ExecStart=/usr/local/bin/Set_WattmanGTK_Settings.sh
    RemainAfterExit=yes
    
    [Install]
    WantedBy=multi-user.target
    And instead of Googling you can also just type "man systemd.unit". systemd is documented like no other piece of open source software.

    Leave a comment:

  • Britoid
    Senior Member

  • Britoid
    replied
    Originally posted by Paul Frederick View Post

    My favorite Desktop Environment failed to work with SystemD so it caused me to go back to using a Window Manager I'd used over 10 years ago. I'm not sure how going backwards is an improvement. Oh SystemD idling at ten times the RAM I used to use has justified having more RAM today. Another win?
    Did you go into a dictionary and pull out random words?

    Leave a comment:

  • oiaohm
    Senior Member

  • oiaohm
    replied
    Originally posted by Paul Frederick View Post
    My favorite Desktop Environment failed to work with SystemD so it caused me to go back to using a Window Manager I'd used over 10 years ago. I'm not sure how going backwards is an improvement. Oh SystemD idling at ten times the RAM I used to use has justified having more RAM today. Another win?
    One learn to type systemd right. Also I don't get where you come up with that ten times the ram idling. Something those found in embedded space is systemd in fact results in less memory management than upstart, sysvinit and busybox init. There is something horrible wrong with the way the non systemd options does things lots of crap is put into environmental variable that end up replicated with most service started so eating more memory. Yes systemd shows some large processors in your process tree but its also caused almost all your services to shrink in memory usage so horrible as it sound systemd is lighter in memory usage over all.

    This is what happens when someone looks at a process table not total system memory usage. Yes this systemd is heavy in memory usage is one of those commonly pulled out bogus arguments that is totally false. Systemd makes it a lot clearer to see how much memory you service management solution is in fact using instead of hiding it in every service started.

    Leave a comment:

  • arokh
    Senior Member

  • arokh
    replied
    Originally posted by ALRBP View Post
    Recently, I had to set up some service on my personal server (Debian) that required several processes to be started and kept active. To do it in the systemd way (I wanted to do so), without any script, I had to create several services with dependencies. Systemd service files are less convenient than good old init scripts when you want to do something complicated (but I must say that, once set up correctly, it works great).
    This is ridiculous, here we have one more guy that just don't know how to read the manual and blame it on systemd. You realize that keeping services and it's dependencies running is it's ace right? Less convenient when doing something "complicated"? Incredible.

    That said, the thing I really do not like with systemd is the idea to put in one big software things that should be independent.
    Your opinion on something you are unable to even operate isn't that interesting, it's like listening to someone who can't drive a car explain about car engines.

    Leave a comment:

  • Paul Frederick
    Phoronix Member

  • Paul Frederick
    replied
    Originally posted by NateHubbard View Post
    This should be a calm and non-controversial topic.
    Let's all post only our thoughts on the technical merits of systemd and how it has improved our lives.
    My favorite Desktop Environment failed to work with SystemD so it caused me to go back to using a Window Manager I'd used over 10 years ago. I'm not sure how going backwards is an improvement. Oh SystemD idling at ten times the RAM I used to use has justified having more RAM today. Another win?

    Leave a comment:

  • oiaohm
    Senior Member

  • oiaohm
    replied
    Originally posted by k1e0x View Post
    I was there during this entire timeline.. and I can see that just fine that it's a strawman. (maybe you believe this is true, who knows) I don't like sysvinit, nor do I like systemd. Just because one is bad doesn't mean the other is good.
    The timeline is not 100 percent pro systemd. It what has got us where are are now. Please go back and read carefully. Its not a strawman arguement the problem has been visible for quite some time.

    Originally posted by k1e0x View Post
    OpenRC is the correct approach. (or other highly functional, modern limited scope init, I'm not solely sold on one thing)
    OpenRC is not complete yet in it cgroups around services or its usage of pidfd to make sure it kills the right process. Its close but not ready.

    Originally posted by k1e0x View Post
    The problem with systemd is the same problem with btrfs (not to start another flame up)
    Too much code was written too fast without any direction or scope. That is a plague in Linux with it's popularity now.
    You are wanting to make something to test out a subsystems in a kernel to make sure they work. What systemd has done is ideal for this. This is what gives us the proper foundation today to build on top of. We would not have stable cgroup v2 today without systemd giving it a heavy work out. Will we always need systemd going forwards maybe no. But we need that event to happen.


    Originally posted by k1e0x View Post
    I've been looking at the development of a new Unix like system Redox, and it's really refreshing to see they are able to look at other systems and do seem to be taking the right approach.
    Yes I do like Redox they have real policy that everything is a file and mean it. This include process interfacing. So Redox comes out box with pidfd equal that is important. Lot of Unix and Unix like lake the means to use a handle to interface with a process instead you only have PID that can have race condition ie your application is attempting to send kill to PID 100 but what happens at PID100 is it crashs and the OS reuses PID100 for some other process now you send kill signal to completely wrong process. https://lwn.net/Articles/794707/ Also Redox has namespaces design fairly close to cgroup v2. So Redox is on the right track to a proper good OS.

    But its going to be if Redox gets the hardware support.

    Linux kernel is on path to a proper good OS kernel by being dragged kicking and screaming in that direction.

    Originally posted by k1e0x View Post
    I had been working with launchd some and where as I don't like it really.
    You don't have equals pidfd or cgroups on OS X. So launchd is fairly much screwed from providing stability as well.

    Basically there is a list functionality you need to make good service management.

    1) You must be able to kill the right process no matter what happens and must fail correctly if that process is already dead when you send signal(no kill any other process that has got the same process id number). This means you must have some solution so you can use a handle to a process that you can use to identify that is the correct process and send a kill signal to it. PID number is not this. pidfd is or like Windows process handles. Linux kernel only gets this year. OS X does not have this. Most Unixs don't have this. Redox does have this. Freebsd does have a different means of doing it as well

    2) You must be able to tell what processes were started by a service. cgroup give this under Linux. namespacing under Redox gives this as well. You don't have this under Windows or OS X properly yet. Windows developers are working on sandboxing stuff to give them this in time..

    3) Your Service management system has to take advantage of this stuff. This is why Openrc is not ready yet.

    4) You need service logging that cannot be lied to.

    5) you need service watchdog so key services can be detected as failed when they have not in fact crashed.

    Originally posted by k1e0x View Post
    *should* do.
    Ironically systemd also does about 5% of what it should do.
    This is wrong about 25% of systemd is what you need for properly managed services. The 5% roughly of what systemd does is what Openrc does is right . Problem here is your idea that 5% of systemd is required todo what it should do is wrong. Openrc is still lacking lot of the cgroup support and proper protection to prevent log faking and is still missing the pidfd stuff and finally where is your service watchdog. Fix all this up and Openrc could be one good competitor.

    So 5% claim against systemd of what it should to is wrong. Please note I am not saying that systemd is not doing too much. 75% of systemd could go away no problems. Openrc is not quite doing enough yet. Openrc does have the foundations that it could be good in time with enough investment in development to close that feature gap.

    There is no point getting these claims wrong because it only means you don't see the work that needs doing.

    Leave a comment:

Working...
X