Announcement

Collapse
No announcement yet.

Systemd 213 Adds A Time Sync Daemon

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

  • #31
    Originally posted by gens View Post
    how do you protect from the OOM killer ?
    did they fix systemd terminating processes with kill at shutdown ?
    hardware watchdog to supervise itself from hanging ?

    audit is the tool to audit, an init is to init
    a quantum leap indeed, by a Planck length that is
    OOMScoreAdjust=Sets the adjustment level for the Out-Of-Memory killer for executed processes. Takes an integer between -1000 (to disable OOM killing for this process) and 1000 (to make killing of this process under memory pressure very likely). See proc.txt for details.
    I think this should address your concern about how it terminates processes at shut down. It's a configurable policy (cgroup, process, mixed, none). If processes are left during shutdown than haven't responded to the policy you can configure http://www.freedesktop.org/software/...temd.kill.html to either sigkill them or not, but it defaults to sigkill.



    Starting with version 183 systemd provides full support for hardware watchdogs (as exposed in /dev/watchdog to userspace), as well as supervisor (software) watchdog support for invidual system services. The basic idea is the following: if enabled, systemd will regularly ping the watchdog hardware. If systemd or the kernel hang this ping will not happen anymore and the hardware will automatically reset the system. This way systemd and the kernel are protected from boundless hangs -- by the hardware. To make the chain complete, systemd then exposes a software watchdog interface for individual services so that they can also be restarted (or some other action taken) if they begin to hang. This software watchdog logic can be configured individually for each service in the ping frequency and the action to take. Putting both parts together (i.e. hardware watchdogs supervising systemd and the kernel, as well as systemd supervising all other services) we have a reliable way to watchdog every single component of the system.
    http://0pointer.de/blog/projects/watchdog.html

    Also, you're going to continue to see problems with systemd if you expect it to be just an init. It just isn't

    Comment


    • #32
      Originally posted by liam View Post
      ...
      oom works on arbitrary point system
      still it won't kill a root process if there is a user one that takes up ram

      first try sigterm, so the process can idk try exit clean
      just sigkill-ing everything right away is just plain wrong
      i wonder the reasoning

      watchdog...
      "This is required to increase reliability and make sure that regardless what happens the best is attempted to get the system working again."
      i stopped reading after that gem

      audit is still a better system and it's scriptable

      systemd is an OS...
      so is linux, and i can't find great many things wrong with linux (none that won't be solved with wayland plus a couple minor ones, that is)
      Last edited by gens; 05-29-2014, 12:29 AM.

      Comment


      • #33
        Originally posted by TeamBlackFox View Post
        That wasn't an attempt at trolling. It was a sarcastic joke from a UNIX user. Sorry you didn't find it funny. I was satiring the humour of yet another block to add to the monolith, it doesn't matter if it uses separate binaries, I'm still no longer a GNU/Linux user.
        We understand that is what you did. What you don't understand is that is trolling.

        Comment


        • #34
          Originally posted by liam View Post
          Also, you're going to continue to see problems with systemd if you expect it to be just an init. It just isn't
          That has been explained to gens hundreds of times, at least a dozen by my personally.

          Comment


          • #35
            Originally posted by gens View Post
            oom works on arbitrary point system
            still it won't kill a root process if there is a user one that takes up ram

            first try sigterm, so the process can idk try exit clean
            just sigkill-ing everything right away is just plain wrong
            i wonder the reasoning
            Your rather brief and almost fragmentary stream-of-consciousness writing style, makes it very hard for other people to understand what exactly it is that you mean.
            Are you against how the Kernel OOMkiller works? or do you dislike the fact that thanks to systemd, end-users can now easily take advantage of such kernel features?

            Sure, many people doesn't need OOMkiller protection on their services, but for those who do, it is a fantastic feature that is easy to use thanks to systemd.

            This feature is just one tiny features out of the many systemd has. But it illustrate a crucial point about systemd, namely that systemd is a plumbing system that makes it possible for distro maintainers and end-users alike to use advanced kernel features. For a long time the problem was that the Linux Kernel got new features, but user-land was very slow in adapting such features. There simply lacked some concerted effort to make things work, which is the reason behind the yearly "Linux Plumbers Conference", and ultimately the reason for why and how systemd is designed.


            Originally posted by gens View Post
            watchdog...
            "This is required to increase reliability and make sure that regardless what happens the best is attempted to get the system working again."
            i stopped reading after that gem
            Again, it is impossible for other people to understand why you stopped reading; was it too tiring?, too many long words? Are you against the principle of watchdogs on systems?

            Really, watchdogs have been a stable of HA computing and the embedded market for years, since they solve an otherwise rather hard problem, namely to supervise the supervisor system and the OS. Even "bug free" systems may hang because of some random bit flip etc. Hardware watchdogs can make recovery fast and cheap, since no there is no need to get a human to power-cycle the hardware. AFAIK, even most desktop motherboards have hardware watchdogs these days.


            Originally posted by gens View Post
            audit is still a better system and it's scriptable
            I have a really hard time understanding why you drag "Audit" into this. Audit seems to be a CAPP audit framework; it doesn't supervise anything, it doesn't prevent anything, it just monitors for changes and report them. Systemd actually supervises all processes instead of merely monitoring them, and can control the limits and behaviour of such processes too, such as preventing them from forking, cap their resource use, starting them or terminating them if needed etc.

            There is a tiny overlap between "Audit" and systemd, in that, thanks to systemd developers, "Audit" actually works on OS containers too (of course, only on systemd systems).

            As for you implying that systemd isn't scriptable, that is just wrong. It just happens to separate configurations in easily parsable text files, from executable code. But the normal GNU tools like grep, tee, sed, ed, bash, works with systemd, in fact, systemd often makes it easier to use such tools.

            Comment


            • #36
              Originally posted by stevenc View Post
              On one of my hosts my process supervisor is this file in /etc/cron.d/ :
              Code:
              * * * * * root pgrep foo > /dev/null || service foo start
              If this triggers, I even get a report (cron already emails stdout to root@localhost, then forwarded to a proper mailbox) with a notification dialog on my workstation (since my email client does that already). Absolutely nothing new was needed for this - no replacement pid1 or new initscripts, no replacement for cron, no replacement logging/notification mechanism in lieu of syslog and/or a properly-configured MTA on the host.
              It would have been better if it was not so easy to fool by renaming one of my process ( by changing argv[0], a trick that work on linux and most *BSD ) to make sure your scriptlet doesn't work, but I guess that your point is that since this duct tape is sufficient for your world, it should be adopted everywhere ?
              For people wanting actual rate limitation, proper process detection and something that do scale ( cause 1 fork per minute is nice for your server, maybe not so good when you start to have 1000 or more container, and likely not fine on a battery powered system ), I guess they need to use something else.

              Comment


              • #37
                Originally posted by gens View Post
                oom works on arbitrary point system
                still it won't kill a root process if there is a user one that takes up ram

                first try sigterm, so the process can idk try exit clean
                just sigkill-ing everything right away is just plain wrong
                i wonder the reasoning

                watchdog...
                "This is required to increase reliability and make sure that regardless what happens the best is attempted to get the system working again."
                i stopped reading after that gem

                audit is still a better system and it's scriptable

                systemd is an OS...
                so is linux, and i can't find great many things wrong with linux (none that won't be solved with wayland plus a couple minor ones, that is)
                I'm having a hard time parsing some of this, but I'll try to address those points which I THINK I understand, however, in general, references to particular issues would be helpful.

                still it won't kill a root process if there is a user one that takes up ram
                I'm not quite sure what this means. Did you read the above? OOMkiller can be disabled for specific processes, so the above is entirely possible. I admit, I may be misreading your question.

                first try sigterm, so the process can idk try exit clean
                just sigkill-ing everything right away is just plain wrong
                i wonder the reasoning
                Again, did you read the links? "Processes will first be terminated via SIGTERM (unless the signal to send is changed via KillSignal=)"

                Comment


                • #38
                  Originally posted by misc View Post
                  I guess that your point is that since this duct tape is sufficient for your world, it should be adopted everywhere
                  That's right. I was suggesting that everyone, everywhere has to use my cron one-liner... or they will become *irrelevant*. Seriously, did you really think that was my point?

                  No, my point was that: if I merely wanted process supervision, it can be done extremely simply with the existing, familiar, commonplace components of GNU/Linux or BSD. The exact method can be based on individual circumstances or expertise.

                  I also tried to illustrate that systemd seeks to replace much that is familiar, and give us something complex that requires learning anew. Therefore I expect it to have many bugs and/or be more difficult to understand during times when it doesn't work as expected I consider these to be 'costs' of migrating to systemd, and I think it's too much to sacrifice.

                  Comment


                  • #39
                    Originally posted by strcat View Post
                    Chrony is lighter than ntpd despite offering some additional features.
                    Chrony is smaller than NTPD since NPTD supports tons of different hardware clocks needed to build and maintain a stratum 1 server. Runtime wise they should both use so little resources to not be noticeable.

                    Comment


                    • #40
                      Originally posted by stevenc View Post
                      That's right. I was suggesting that everyone, everywhere has to use my cron one-liner... or they will become *irrelevant*. Seriously, did you really think that was my point?

                      No, my point was that: if I merely wanted process supervision, it can be done extremely simply with the existing, familiar, commonplace components of GNU/Linux or BSD. The exact method can be based on individual circumstances or expertise.

                      I also tried to illustrate that systemd seeks to replace much that is familiar, and give us something complex that requires learning anew. Therefore I expect it to have many bugs and/or be more difficult to understand during times when it doesn't work as expected I consider these to be 'costs' of migrating to systemd, and I think it's too much to sacrifice.
                      My point is that you simple way is buggy. It doesn't handle stuff like rate limitation ( hello flood of mail if you cannot start the system at 2AM ) , it can be fooled by a unprivileged user, it doesn't scale. So yeah, that's simple to make crappy code. And so you just show that if we depend on the individual expertise, then we end with a potential share of crappy systems. Now, for sure, if you jusge the quality of others people code based on the number of code in your one liner, that's likely bad. But not everybody do have a ratio of 1 bug per line.

                      Comment


                      • #41
                        Originally posted by stevenc View Post
                        That's right. I was suggesting that everyone, everywhere has to use my cron one-liner... or they will become *irrelevant*. Seriously, did you really think that was my point?

                        No, my point was that: if I merely wanted process supervision, it can be done extremely simply with the existing, familiar, commonplace components of GNU/Linux or BSD. The exact method can be based on individual circumstances or expertise.

                        I think the notion, that a modern OS shouldn't have inbuilt process supervision, but instead relying on its end users to program such a solution, is undefendable.

                        The OS should provide the framework and programs, just like systemd does, so that Linux Security Modules (LSM) and other kernel features can be used. The end-users should tweak declarative text config files, not be forced to program just to get a bare minimum functionality. Relying on declarative text config files like systemd does, also makes it much easier to machine parse the config files, which is necessary these days with automatic mass deployment of servers.

                        The non-systemd distros doesn't seem to have any standard process supervision system, in fact, most of them doesn't have anything at all in that regard. The solutions that exist, are really quite limited and doesn't increase security by hardening the process. What you learn in one distro, can't be used on another.

                        All systemd Linux distros now have automatic process and service supervision, that can utilise powerful kernel features that dramatically increases security and stability. The supervision chain is total, including the supervising process itself, and is configured with declarative text files, that are easy for both humans and machines to parse and edit. Once learned, the knowledge can be extended to all systemd distros.


                        Originally posted by stevenc View Post
                        I also tried to illustrate that systemd seeks to replace much that is familiar, and give us something complex that requires learning anew. Therefore I expect it to have many bugs and/or be more difficult to understand during times when it doesn't work as expected I consider these to be 'costs' of migrating to systemd, and I think it's too much to sacrifice.
                        Learning new stuff all the time just goes with the territory of computing. The main driving force behind the changes are that the problem domain keeps shifting, often increasing in both scope and complexity. The 1980-90 way of running a server is dying. These days it is all about virtualisation, OS containers, Big Data, Cloud Computing, mass deployment, extreme resource utilisation, massive scaling, and doing all this in a secure and easy manner. Any OS that can't compete in these domains will become irrelevant in a short time.

                        So while sysvinit (though always a hack) would work in well enough on a single server, running on metal, dishing out a few simple services like http, or ftp, while idling most of the time, it simply doesn't work well for modern computing problems.

                        There you have it; if you want work in IT, you just have to learn something new all the time, because they way we use computers change. People not making a living in IT can "stop the world" if they want to by using old software: WordPerfect 5.1 for DOS is still an excellent word processor and may fit the work flow of somebody perfectly well in this day and age. But it is not a general solution for the majority of end-users.

                        Like it or not, if you want to make a living using Linux, you just have to learn to use systemd. Systemd covers a lot of ground, so there is much to be learned. However, the documentation is there, and once you get the principle behind each systemd component it isn't hard to get to know.

                        Comment

                        Working...
                        X