Announcement

Collapse
No announcement yet.

Systemd 212 Brings Remote Journals, Other New Features

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

  • Systemd 212 Brings Remote Journals, Other New Features

    Phoronix: Systemd 212 Brings Remote Journals, Other New Features

    Systemd 212 is now available as the latest version of the widely-used open-source init system. The systemd 212 update brings both bug-fixes and new functionality...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    So, it just assimilated anacron and any syslog daemon with a network broadcast option. I do like systemD, but why the duplication? What can systemD do better than anacron?

    Comment


    • #3
      I was hoping for systemd-pacmand. Last year the Arch Linux Team made a pretty funny April fools joke about how they envision pacman to integrate with systemd.

      Comment


      • #4
        I hope that they will be able to maintain all the features in the future. Seems like systemd is a big stack these days. Cool features btw, fan of networked journaling.

        Comment


        • #5
          Originally posted by blackout23 View Post
          I was hoping for systemd-pacmand. Last year the Arch Linux Team made a pretty funny April fools joke about how they envision pacman to integrate with systemd.
          Rofl.

          Originally posted by Allan Mcrae
          When updates are found, it schedules a reboot of the system (hence the need to integrate systemd). At the moment the timing of the reboots is not configurable, but a timer will pop-up to allow you to delay it for a preset amount of time.

          Comment


          • #6
            Originally posted by blackout23 View Post
            I was hoping for systemd-pacmand. Last year the Arch Linux Team made a pretty funny April fools joke about how they envision pacman to integrate with systemd.
            It would be funny if they'd do another one this year also based on SystemD!

            Comment


            • #7
              Originally posted by Rexilion View Post
              So, it just assimilated anacron and any syslog daemon with a network broadcast optionfio like systemD, but why the duplication? What can systemD do better than anacron?
              Things systemd timers do better than anacron would be that they're part of systemd and thus share all the benefits of systemd units. That is to say that in addition to being a timer (anacron functionality) they have the benefit of systemd logging, process management, resource management, dependency tracking, activation conditions (ConditionPathExists, ConditionACPower and so on), actions to take on failure or different actions based on exit code. timers not only activate service files, but can also activate targets which in turn activate all the enabled units associated with that target so you can have timers activating a suite of services and jobs.

              But yeah, these are just some of the things. I can probably think of more if I read every single systemd manpage
              Last edited by renkin; 26 March 2014, 03:31 PM.

              Comment


              • #8
                Originally posted by renkin View Post
                But yeah, these are just some of the things. I can probably think of more if I read every single systemd manpage
                Here's Lennart's take on the subject:

                So, here's why you want systemd time events:

                *systemd timer events allow you to make use of the same execution parameters of any other systemd service, which means you can limit resources, change users/group ids, set nice values, oom score, IO scheduling class, IO scheduling priority, CPU scheduling policy, CPU scheduling priority, CPU affinity, umask, timer slack, capabilities, secure bits, control group memberships, control group attributes, network access, private /tmp, namespaces, system call filters, ... individually for each job.

                *As the services started by a timer unit is a normal service it can pull in arbitrary dependencies on activation. That means you can actually sanely write cron jobs that depend on what they need.

                *As timer events are just one way to activate a unit you can actually combine that, so that you can spawn a service triggered by different events. Think: there's now a sane way to invoke something on the command line + at boot + if hw is plugged in + on a time event or if the user starts it explicitly, and the service will be executed in the exact same environment.

                *As timer events are just like any other units you now have a sane way to enable and disable them: "systemctl enable" and "systemctl disable".

                *All output of systemd timer events ends up in the logs, and is indexed by the event.

                *systemd can schedule time events both on monotonic times (think: run something every so and so often regardless of timzones, DST, the user mucking with the clock, broken clock, clock battery gone...) and on calendar times.

                *systemd calendar time events are more fine grained than cron (1s precision)

                *systemd calendar time events are more expressive (you can have repetitive and non-repetitive events, you can match on years, and you can actually match a week day at the same time as a day of month). And also I'd claim they are easier to write and especially read than cron time events. (See the lower part of http://www.freedesktop.org/software/...temd.time.html[1] for details)
                the systemd timer scheduling is a bit more energy efficient as systemd wakes up the CPU only when the timer elapsed, and not repeatedly as cron does

                *In cron if you wanted to avoid that slow running services are spawned multiple times you had to invent your own locking in the job. In systemd that's implicit, as the trigger is just a trigger, and the service will never be started at once.

                *You can even express timer events that are scheduled based on the finish time of the previous execution, i.e. for example to say that there should always be 1h between executions, even if each of them takes 2h.

                *You can combine timer events easily. e.g. "5 min after bootup + every day at 6am".

                *You now have a nice way to stop/kill a cronjob (and all its children), and only that one cron job, with "systemctl stop" and "systemctl start"

                *You now have a nice way how you can figure out to which cronjob a process belongs to, "ps xawf -eo pid,user,cgroup,args".

                *External programs can query all details about timers and the jobs. Execution status, when they ran the last time, and so on. There's a pretty complete, documented API for that exposed on the bus.

                *We now track failed cron jobs nicely, and just typing "systemctl show" will show them to you.

                *You now can establish cronjobs only in certain system states. For example, you can queue a cronjob only if the network is up, or suchlike. Think of cronjobs that are pulled in by the equivalent of classic sysv runlevels, only.

                *And yeah, the scheme makes timer events uniform with other triggers, so it's simpler to understand for newcomers...

                The interesting bit about all of this is that the code necessary for implementing all of this is pretty short, since all the complex bits (spawning/supervising a process in a precisely defined execution environment, pulling in deps...) is just the stuff we do anyway for normal services. The only additions for supporting timer events, was basically a parser for the timer expression language and a bit of code to tell the kernel to actually wake up systemd when the timer triggers.
                So, yeah, the code we had to write was small, the benefits gained throught it are substantial, so we did it.
                I figure embedded people will start making use of all of this first.
                -Source

                Comment


                • #9
                  Originally posted by Rexilion View Post
                  So, it just assimilated anacron and any syslog daemon with a network broadcast option. I do like systemD, but why the duplication? What can systemD do better than anacron?
                  Consider it this way - on classic Unix, you have a variety of different daemons (e.g inetd, crond, atd) running at all times, all of them with the exact same job, that of starting other processes in response to some event.

                  In systemd, we have one daemon that's designed for the task of starting other processes in response to various events - all that's happened here is that it's gained support for a new type of event (i.e time-based). Why would you want separate daemons for each event (e.g connection, recurring timer, one-short timer), when the core function of each of them is identical?

                  Comment


                  • #10
                    Originally posted by Delgarde View Post
                    Consider it this way - on classic Unix, you have a variety of different daemons (e.g inetd, crond, atd) running at all times, all of them with the exact same job, that of starting other processes in response to some event.

                    In systemd, we have one daemon that's designed for the task of starting other processes in response to various events - all that's happened here is that it's gained support for a new type of event (i.e time-based). Why would you want separate daemons for each event (e.g connection, recurring timer, one-short timer), when the core function of each of them is identical?
                    One very simple reason: SINGLE POINT OF FAILURE !!!!

                    The classic Unix approach eliminates SPOFs and gives you a wide choice of tools to use. Systemd is the exact opposite (I'd call it the Microsoft way of doing things).

                    Anyway, personal experience: I installed systemd on my Gentoo box to get back consolekit functionality. I tried to use it as init system, but once it mounted my LVM devices as /dev/dm-X it was quickly reduced to just udev/logind provider. I don't care who is responsible for the mess (systemd devs or gentoo maintainers). Such idiocies have no place in a modern system (why the hell does LVM have a vg/lv naming option if nto for clarity ? /dev/dm-X is not clear at all).

                    Comment

                    Working...
                    X