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 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


                  • 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.
                    /var/spool/cron pay to read on.
                    http://man7.org/linux/man-pages/man8/cron.8.html
                    So using cron was no root privilege required.

                    Reason why the crontab application would not work for users had been disabled by the distribution or administrator. Due to user created cron being disabled by default in most cases it never got updated with a .d option. Reason for crontab application being disabled is a stack of historic pranks and being hard to trouble shoot who was being the ass. This is the difference between Linux and Unix problem resulting in why cgroups have to be used.

                    Really this is kind of why systemd is not that bad for me that it consumed cron. Systemd user mode implements timers wrapped in users cgroup so you can trace to who is directly responsible. Systemd user timers by default have a really smart feature they don't run if the user is not logged in so cannot be used to prank a different user as simply.

                    This is area that been broken that systemd in fact provides a working solution to. There are some third party addons to systemd that bring crontab application back and it creates systemd.timer files in user account.

                    Originally posted by jacob View Post
                    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?
                    Lot of this problem would be solved for cron if .d had been implemented on /var/spool/cron allowing each application just to drop it own configuration file. Of course this does not change why user settable cron was being disabled by default being the lack of traceability.

                    Originally posted by jacob View Post
                    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?
                    Does not need to be running in background all the time cron just like a systemd timer can start basically what ever. Yes you can query if a user has X11 session running and then processed to run application with that display output from cron or a systemd timer. Lack of dependable session management now does come a problem where if you fail to detect that the application is running you have a growing number of that application running and worse with possible no record in the process table that it was cron doing it. Yes not using cgroups and it forked off the right way under Linux from cron so no record how application was started in process table and cron not required to log starting things have fun debugging this.

                    Of course gnome looking at systemd user mode idea of session managment does mean you could say timer depends on x service application being running so systemd would start the correct application only if required.

                    Session management and process tracking under Linux both to work come a use cgroup feature so we have sanity. Now does this have to be systemd long term no. Does it have to be something setting the cgroups up yes.

                    Cron being a ass to use is because it was broken. API really required for cron file based ABI would have been good enough. Lot miss why the .d feature did not come to the user cron configuration directory. Yes that security problem with lack of accountability. The .d directories come out of the Linux world so of course they did not appear anywhere where Linux was not functional. Yes having not functional sysvinit result in cron not being functional. This is not the only domino effect from sysvinit limitations to other parts in Linux.

                    Comment


                    • Originally posted by audir8 View Post
                      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:
                      That one turns out to be mega screwed. This was kernel update and systemd caused trouble at the same time. Updating systemd udev to support future kernel change resulted in breaking it on prior kernels.

                      Some of these connectivity issues just turn pain in ass. It not like Linux is unique for it there are sometimes windows input driver issues that are caused the same way.

                      Originally posted by audir8 View Post
                      Android doesn't use systemd
                      That fairly much Android aversion to LGPL for anything more than they have to.

                      Originally posted by audir8 View Post
                      others in an embedded environment that do get rid of the complexity before they do, probably just to reuse unit files.
                      Embedded developers are very good to watch with systemd. You see systemd cut down to the point of insanity in embedded. No dbus, no journald, no logind. Things they are after is the unit based service management with cgroup controls on resource usage and systemd watchdog system everything else when they build systemd from source is basically disabled. So yes embedded do strip a lot of complexity out of systemd but what they use is build from the mainline systemd sources with no code modifications. Purely configuration.

                      Comment

                      Working...
                      X