Announcement

Collapse
No announcement yet.

Debian May Need To Re-Evaluate Its Interest In "Init System Diversity"

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Originally posted by audir8 View Post
    This can be cgroup-utils, syslog, cron, etc.. in many cases the user/developer api for these services is same even with different implementations. The average user doesn't care about any of this, they care about what udev/networkmanager/pulseaudio/xrandr can do for them. Make that functionality consistent with decent fallbacks over rolling or monolithic upgrades and there would be less distro hopping and more Linux adoption in general. You can have a same-looking networkmanager almost anywhere and it works! More of that please.

    The user/dev experience with systemd is worse in some cases (wtf does masking a service need to exist?), and marginally better in others (logging). If you want to make an improvement, you can do it with better APIs all around. There is no need for a user or developer to use most of the functionality in the systemd repo if they just want to deploy a service. Interfacing with the Linux system in general is a much bigger problem, and cgroups is about the last place I would start. Do you know what would be the first? f*&^ing temperatures and cooling!
    Agree..

    Comment


    • Originally posted by You- View Post
      A major problem with systemd alternatives is that they have not moved with the times. They should have developed a shim to read systemd style service files. That way most startup scripts would no longer be necessary and the syntax for services could become standardised.

      No one has done this.
      So... If the scripts are not needed,
      Why in Corporate Midlewares, you have services that to create a deamon for them you need zillions of parameters, environment variables and another stuff more..
      How will be implemented, in a very poorly capable, systemd scripting language?

      Some people say that scripts are bad, but systemd created a systemd own language for it( the systemd service file, itself is a script.. ).
      After all, the user end with, the service file plus the real script( the one that configure the real service ),

      So the user end with some sort of 2 services to launch 1 real Service( the systemd service - Loading the systemd service file, and the real service - loading the real application )..

      I don't know what would be if they liked..
      Last edited by tuxd3v; 09-19-2019, 08:29 PM.

      Comment


      • Originally posted by k1e0x View Post
        I've heard that before, I've always found it reliable. (and yes you need to use it correctly, on the actual daemon process not a script.)
        Depends on what the deamon is. Apache, nginx, postgresql, mysql, cups and many more can themselves run programs that can get disconnected from parent. Monitoring the actual deamon process does not stop process leaks.

        So this use supervisord correctly and not using scripts it still breaks. What you have given me here is a works for me arguement digging your head in the sand not wanting to admit it does not work for a lot of groups.

        Originally posted by k1e0x View Post
        It's a bandaid anyhow.. if your services are dying unexpectedly there is something wrong with the system. (in my book maybe not yours)
        Yes it a bandaid. Not all cases do you have the means to run a perfect system. I have run into cases with brother printers closed source driver leaking processes and been really thankful for systemd cgroup solution to kill everything in cups after printing to get everything back in order. So sometimes you know what is wrong with no option to fix it.

        Originally posted by k1e0x View Post
        I believe OpenRC implements this too but they also have their own called supervise-daemon. I'll watch it with my eyes before I trust systemd tho. lol
        https://wiki.gentoo.org/wiki/OpenRC/CGroups

        I don't mind openrc as long as you remember to turn cgroups on.

        Originally posted by k1e0x View Post
        If you haven't figured it out yet.. I like simplicity. I want to run top on the box and see everything the system is doing in one page and know everything in there.
        I like different simplicity. I like cgroups around services so I can see what a service has in fact started so I can blame the right service for eating me out of cpu/ram/io. I really don't like when you have a leaked process that is eating you out of house and home with no clue on what service started it as you end up with solutions like sysvinit, Runit, daemontools and supervisord.

        I also don't like when thing have gone out of control and I tell stuff to stop and they don't. Think about this when a system is working perfectly I mostly have to-do nothing to it. When I have to work on a system things have gone wrong so I want my debugging of a system that has problems as simple as possible.

        I want service management to have set up the information so when I have to debug the problem is straight forwards to see what service was responsible for the disaster so the first time the disaster happens I can fix it so it never happens again without any guess work.

        Process leaks cause the following problems that are fixed by cgroups.
        1) failure to be able stop/restart service
        2) Logging information from a leaked process that does not seam to be associated with anything.
        3) Failure to track problem quickly to what service was the cause.

        cgroups provide io limitation and memory limitation in systemd as well. This is useful to prevent a service from eating all the resources as well.

        By the way the systems I run a top command will most likely give you between 2000-5000 processes so not a single page of top. Yes services with process per connection makes a long list very quickly. Yes 2000-5000 is depending on time of day what one it closer to. My printed out cgroups is under a page. Even your basic desktop setups for Linux get over 200 processes showing in top.

        These more complex systems chasing down a process leak is a major pain in the ass without cgroups.

        If you can run top and everything appears on 1 page you are running very simple systems. Not all of us are running stuff that simple and once you are not running stuff that simple you cannot manually search down process leaks without the assistance information of cgroups on Linux.

        Really a lot of people who are running ultra simple init/service management normally turn out to be using container/vm containment. If that the case supervisord not the correct solution either. Like for example kubernetes has what is called Auto-Healing Containers and the like. So your orchestration system in container/vm solutions do what supervisord/runit/demaontools... do and work in all cases.

        I can understand someone wanting sinit that is a super basic init for container. No service management because when using orchestration inside the container you are not needing service management as the orchestration is doing service management properly at the container/vm level Why would I want more service management to deal with in this case supervisord/runit/demaontools/systemd... basically comes duplication in this use case. Worse supervisord does not match the reliability of the orchestration solutions.

        See my problem with supervisord now. Simple systems vm/containers its extra part you don't need. More complex systems supervisord useless because it does not produce the information or the tools to debug the more complex solution when things go wrong.

        If something provides service management it need to work. I have cases that don't need service management because I have orchestration as well. So my solutions go from very big in process count to very small.

        What I am after will work in all cases not just only if I have a few processes per system that I can see in 1 top screen.

        Comment


        • Originally posted by danmcgrew View Post
          PulseAudio? Is my sound any better?
          Exactly as it was, but more usable.

          Wayland? Are my graphics any better?
          Yup.

          Systemd? Is my system more stable and/or boots faster?
          Immensely.

          Comment


          • "Stop caring about sysv init", lol. Like if someone has been really maintaining this, doh. It always gave nasty shit in Debian. And still does - for services that haven't gone systemd so far. I'm sorry but sysv scripts tend to backfire or misbehave and utterly lack diagnostic & reasonable management - which makes it quite frustrating experience. Somehow quality of sysv scripts in debian always been below of what anticipated.

            In case of systemd obvious advantage is that core complexity is pushed out to some project that more or less sorted things out - and there is privileged "core" that can create sandboxed "arena" for new processes.. Something that sysv approach never achieved - forcing everyone to reinvent the wheels here and there and struggle a lot if they're serious about e.g. hardening system security. So while I'll say systemd eventually being annoying with its unrestricted growth and some strange design decisions (e.g. dbus crash = whoops, it gets nearly uncontrollable) - I'm yet to see anything better than that.

            As for boot speed, systemd beats crap out of "usual" sysv init any day. And it also at least writes logs, so if something fails to start for whatever reason, I can get idea why. In sysv most scripts do not give crap about exit codes or process crashes and I had to write all debug logging myself. Sorry but is sucks too much. Especially when you need to start your own service that isn't packaged by distro.
            Last edited by SystemCrasher; 09-19-2019, 10:15 PM.

            Comment


            • Originally posted by jacob View Post

              I think a more fundamental problem is that the systems you mention (cron etc...) follow the "everything is a text file" concept which was perfectly fine... in the 1970s where computers were static, centralised, had a full time sysadmin and the concept of third-party user applications didn't exist. But today we need a clean break from that and move to an era where everything is an API instead. Cron for example has no API at all. With cron there is no way whatsoever the developer of an application (I'm specifically saying DEVELOPER, not the admin!) can say "I need this function to run every 6 hours" for example to update F/X rates and be sure that it's indeed going to happen as required. Note also the deliberate use of the word function as opposed to shell script. Plus the sacrosanct "choice" means that whatever clunky and inadequate ersatz the developer will implement to work around this stupid limitation, it may not (and probably will not) work anyway for totally arbitrary and unpredictable reasons.

              Put another way, Linux was born out of Unix which was a sysadmin's OS. It's imperative that it becomes a developer's OS instead.
              You're missing the point which is cron functionality doesn't need to be anywhere near something that is mainly managing boot configuration and services. https://stackoverflow.com/a/879022/1210336 You can put files in directories too with cron, and you can set it up so users can do it too.

              Linux already is a developer's OS, it's the reason WSL exists. I can see spstarr 's point about being scalable in the cloud and unit files accomplish this, but as a developer I embrace KISS and don't mind the occasional bash. Systemd's unit files are the API that can be improved or used by another init system.

              As somebody mentioned: http://www.ocsmag.com/2016/10/19/sys...gh-complexity/ I have a story too: I have maintained a single functioning install of Ubuntu since 8.04 (a couple minor upgrades, but then mostly LTS upgrades, running 18.04 now). Only ~half the times did it upgrade without issues. Almost every package is set to manual install and I'm sure there's some cruft I haven't removed, but I still use it as a backup laptop (10 yo C2Quad isn't too shabby). This wasn't that hard to do because Gentoo. The last problem I had with it was systemd related and it was every bit as obtuse to troubleshoot as the post lays out and implies. To newcomers, or those who learned about it before jumping in, I'm sure the experience of using systemd was better. I'm sure this accounts for a lot of the hate that systemd gets, that and the feature creep. Anyone can call it "system manager", but no one has to use it. Over time, my opinion hasn't changed. I prefer things that do one thing well, and not try to reinvent cron or inetd among other things. It's mostly all udev/dbus/kernel in the back anyway.
              Last edited by audir8; 09-19-2019, 10:15 PM.

              Comment


              • Originally posted by spstarr View Post
                Please don't assume you know me. I know more about both given I've been there from the very beginning of Fedora .... anyhow. I know about that history... it doesn't change the fact a lot of people I know personally in Red Hat or who were in Red Hat HATED systemd and refused to even use Fedora for their development... kernel development....
                So was I. The point is calling out the claim systemd was forced on Fedora/RHEL which is incorrect as majority of developers and administrators gladly got rid their old shell scripts and the fact sysemd is backward compatible with the old sysint script. Without the hard work done by the systemd developers to implement a real system management for the Linux kernel, we would remain in the same impasse that happened over nearly twenty years.

                Comment


                • Originally posted by jacob View Post
                  I think a more fundamental problem is that the systems you mention (cron etc...) follow the "everything is a text file" concept which was perfectly fine.
                  That is not the problem systemd is still a lot of text files.

                  The problem is simpler. Linux is in fact a Unix like operating system. As in Linux behaves a lot like Unix but it has key differences to a true BSD based Unix or a BSD. Under Linux every property on a process associating it with other processes can be changed by process except of cgroup. BSD based like most Unix and freebsd/netbsd... you cannot change your parent association.

                  Remember sysvinit has two incorrect presumes for Linux. sysv PID numbers were not recycled so when they are horrible things can happen. The other presume same mistake cron has that a process will not disconnect itself from parent.

                  Please note things have changed for cron from the first version. First version of cron everything had to be in a single text file today you see /etc/cron.d and other .d directories. Yes file IO stuff is a API. What .d was for developers so they could put there own file in the .d directory and have the process pick configuration with having to mess with other parties configurations. So yes cron has a API written around file actions to configure cron. But cron depend on the process tree to remain correctly assembled to double check everything was working.

                  cgroups added another section to files and when you use timers in systemd whey they are running they should appear as file access. Montoring a cgroup directory will tell you if the timer process is in fact running. Systemd has a lot of file API stuff.

                  Having a API is no good if when you store settings you cannot tell who created what like Windows. How setting are stores on the file system is something very important to be right.

                  Comment


                  • Originally posted by audir8 View Post

                    You're missing the point which is cron functionality doesn't need to be anywhere near something that is mainly managing boot configuration and services. https://stackoverflow.com/a/879022/1210336 You can put files in directories too with cron, and you can set it up so users can do it too.

                    Linux already is a developer's OS, it's the reason WSL exists. I can see spstarr 's point about being scalable in the cloud and unit files accomplish this, but as a developer I embrace KISS and don't mind the occasional bash. Systemd's unit files are the API that can be improved or used by another init system.

                    As somebody mentioned: http://www.ocsmag.com/2016/10/19/sys...gh-complexity/ I have a story too: I have maintained a single functioning install of Ubuntu since 8.04 (a couple minor upgrades, but then mostly LTS upgrades, running 18.04 now). Only ~half the times did it upgrade without issues. Almost every package is set to manual install and I'm sure there's some cruft I haven't removed, but I still use it as a backup laptop (10 yo C2Quad isn't too shabby). This wasn't that hard to do because Gentoo. The last problem I had with it was systemd related and it was every bit as obtuse to troubleshoot as the post lays out and implies. To newcomers, or those who learned about it before jumping in, I'm sure the experience of using systemd was better. I'm sure this accounts for a lot of the hate that systemd gets, that and the feature creep. Anyone can call it "system manager", but no one has to use it. Over time, my opinion hasn't changed. I prefer things that do one thing well, and not try to reinvent cron or inetd among other things. It's mostly all udev/dbus/kernel in the back anyway.
                    That's simply not true. A user facing application should not have to handle the click on a button in its UI by generating and dropping some kludgey shell script in some cron directory. And it can't do it anyway if it's not running with root privileges. Are you suggesting that a user app should implement logic to somehow parse, update and save the user's crontab? How on Earth is that supposed to be... not even better, but simply acceptable?

                    And what are you going to do with your cron job, by the way? How is it going to call back into the application's code to trigger whatever action needs to be taken? By using dbus? How dareth thou, you heretic! Joe Unix Maniac's Choice(tm) is not to ever have dbus "on his system", so that won't work. Does the app then need to somehow be running in the background all that time and listen on some socket? How is it going to achieve that (without ever assuming for one second that the user is going to start writing scripts or such), since we have precious Choice(tm) of two dozen desktops or so, each with its own incompatible session management semantics and every single one of them broken by design?

                    So by now the idea of clicking on a simple button that says "do this every X hours" requires actually implementing a complex parser (with file locking and capable of handling all the various failure modes of POSIX IO), socket management and some form of self-managed daemon mode that tries to work around all the mutual incompatibilities that people insist on keeping? Yeah, no. I'll rather have systemd and dbus and not bother supporting anything else, thank you very much.

                    Comment


                    • Originally posted by jacob View Post

                      That's simply not true. A user facing application should not have to handle the click on a button in its UI by generating and dropping some kludgey shell script in some cron directory. And it can't do it anyway if it's not running with root privileges. Are you suggesting that a user app should implement logic to somehow parse, update and save the user's crontab? How on Earth is that supposed to be... not even better, but simply acceptable?

                      And what are you going to do with your cron job, by the way? How is it going to call back into the application's code to trigger whatever action needs to be taken? By using dbus? How dareth thou, you heretic! Joe Unix Maniac's Choice(tm) is not to ever have dbus "on his system", so that won't work. Does the app then need to somehow be running in the background all that time and listen on some socket? How is it going to achieve that (without ever assuming for one second that the user is going to start writing scripts or such), since we have precious Choice(tm) of two dozen desktops or so, each with its own incompatible session management semantics and every single one of them broken by design?

                      So by now the idea of clicking on a simple button that says "do this every X hours" requires actually implementing a complex parser (with file locking and capable of handling all the various failure modes of POSIX IO), socket management and some form of self-managed daemon mode that tries to work around all the mutual incompatibilities that people insist on keeping? Yeah, no. I'll rather have systemd and dbus and not bother supporting anything else, thank you very much.
                      At this point the only thing left to say, and what I realize is that Linux is a server and cloud focused OS. It's systemd's focus. Features offered by it are no different from the kernel/steam connectivity issue recently and causing problems like this: https://github.com/systemd/systemd/issues/13553 You don't mind the complexity or features because it helps you, but it can in fact be too complex for the average user. You can make it as easy as a drag and drop GUI, but the complexity is still there. The average web dev or backend dev like me doesn't care about init systems either, I'm fine with any sane API, and systemd unit files don't seem so bad at all once you learn about them.

                      Yes, server shit does eventually come down to the desktops, but server shit bakes for ~10 years so until the bugs are gone and it usually takes another few years before being accepted by someone who doesn't manage a cluster. No average user using Ubuntu or Fedora is going to file such a systemd bug on github, but here we are. Hope the complexity all works out in another few years. Android doesn't use systemd, and others in an embedded environment that do get rid of the complexity before they do, probably just to reuse unit files.

                      Comment

                      Working...
                      X