Announcement

Collapse
No announcement yet.

Arch Linux Moves Forward With Systemd

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

  • Arch Linux Moves Forward With Systemd

    Phoronix: Arch Linux Moves Forward With Systemd

    The latest monthly snapshot of the Arch Linux rolling release install meda is now using systemd rather than SysVinit for booting up the system...

    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
    It's not quite clear from the article, but notably only the install medium uses systemd, the default install is still sysvinit/initscripts. This will change in the near future, but they're not quite ready to recommend it for all new installs yet.

    Comment


    • #3
      Arch supports almost every DE/WM out there (including Cinnamon, Unity and Gala through the AUR), and it's rolling release is awesome. It's the way all software distros should work, IMO. Unfortunately it's waaaay to difficult to set up for common users, and maintenance sometimes becomes a challenge when core features change (like the move to systemd). There really needs to be a distro and software-center based off Arch Linux which is designed to be as easy to use a Ubuntu/Mint... that would be awesome, and I hope we see it some day soon.

      Comment


      • #4
        Originally posted by F i L View Post
        There really needs to be a distro and software-center based off Arch Linux which is designed to be as easy to use a Ubuntu/Mint... that would be awesome, and I hope we see it some day soon.
        http://chakra-project.org/

        More here: https://wiki.archlinux.org/index.php...tions_(Active)

        Comment


        • #5
          Originally posted by mdias View Post
          Chaka is no longer based on Arch and has its own completely separate package repository. Also it only provides one desktop environment and it is not a bleedin edge rolling release distribution like Arch but rather has it's own half rolling release model (stable core, rolling applications).It's not as easy to use as Mint or Ubuntu either because it lacks proper graphical package manager (it's in progress) and the installer is still what it is.

          Comment


          • #6
            Originally posted by Teho View Post
            Chaka is no longer based on Arch and has its own completely separate package repository. Also it only provides one desktop environment and it is not a bleedin edge rolling release distribution like Arch but rather has it's own half rolling release model (stable core, rolling applications).It's not as easy to use as Mint or Ubuntu either because it lacks proper graphical package manager (it's in progress) and the installer is still what it is.
            Thanks for the correction/info. I use "vanilla" Arch myself and last time I heard about Chakra it was based on Arch, I guess me and the arch's wiki are not up to date

            Comment


            • #7
              Originally posted by F i L View Post
              Arch supports almost every DE/WM out there (including Cinnamon, Unity and Gala through the AUR), and it's rolling release is awesome. It's the way all software distros should work, IMO. Unfortunately it's waaaay to difficult to set up for common users, and maintenance sometimes becomes a challenge when core features change (like the move to systemd). There really needs to be a distro and software-center based off Arch Linux which is designed to be as easy to use a Ubuntu/Mint... that would be awesome, and I hope we see it some day soon.
              Add Software Center to Repos
              Make a Spin-Off
              Add all needed Packages from the Spin of to the Repos
              Add an dumb-resistent installer und support it by the spin of theam (some thing like the installer from suse)
              Push more main power to arch to get more packages from aur to the repos, cause its not always easy to use the AUR to get software.
              All distros, espeially Arch got easyer to use since the most gui tools that allow the aministration without the shell were moved from the distros to the DEs or cause they are no longer needed.

              Comment


              • #8
                Why are they jump head first into this! Sure provide "support" for systemd as an option BUT making it the default init system ...

                systemd right now is a trainwreck, they are blaming the kernel for effects they have created, they are coming up with arse about face "workarounds" for a process they broke which was fine before

                just qq?

                There is udev regression going on and they are blaming the kernel. The kernel dev's have a very strong view about not breaking externals YET udev are...




                Originally posted by linus
                >
                > Calling out from inside the kernel and blocking in a firmware loading
                > userspace transaction during module_init() is kind of weird.

                It's *very* common.

                I personally would prefer if drivers did their firmware loading not at
                probe time, but at device open time, but that's not always necessarily
                possible. More importantly, it's not actually how things are done.

                So udev had better be fixed. The whole "no regressions" should be the
                rule not just for the kernel, but it damn well should be the rule at
                *least* also for projects like udev that are so closely related to the
                kernel.

                The "I wish things were otherwise than they are" mindset is wishful
                thinking. Reality is that probing - and firmware loading - happens
                from the module init routines quite often, and it clearly used to
                work. So udev broke. Fix it, don't argue that you wish things were
                otherwise.

                Linus


                OR how udev/systemd fucked with df and umount (cornerstones of UNIX since year DOT!!!)



                so due to the retarded nature of how systemd works it "misreports" things AND they want df fixed ...
                They want/need mtab to be a symlink

                mmmkey...
                but their asshattery also broke umount


                NOT only that


                Their proposed workaround is.... alias df...


                alias df='df -hT | grep -v tmpfs | grep -v cifs | grep -v /usr/local/sftp-homes | grep -v rootfs | grep -v /var/named/chroot | grep -v /var/tmp'


                Thats fucking disgusting! and they shouldn't be calling themselves developers! sure go develope a new init system, the nextgen init (even though openrc pretty much does what is required and is fast... ok not as fast as sysd and speed is their only benefit...) but FFS sort your shit out before you ram it down peoples throats (and by ramming it I mean absorbing udev in making people who just want udev life a bit harder).

                this shit needs to be sorted!
                right now if systemd segfaults guess what happens to the system? reboot - the benefits of have a VERY simple small codebase for the init process WHICH systemd decided to ignore as well as ignoring the cornerstone of UNIX that a program does one task and does it very very well

                Comment


                • #9
                  Originally posted by Naib View Post
                  Why are they jump head first into this!
                  Originally posted by tomegun (Arch Developer)
                  Timing:

                  We don't have a date yet, but we have a list of blockers (we need the next releases of util-linux and sysvinit at least, and we need full coverage of systemd service files for all packages that have rc scripts). So I guess the best I can say is "when it is ready". There is also the added wish to do it "as soon as possible" as it will make the packaging of the next versions of certain packages (gnome, polkit at least, but probably many others that I'm not aware of) much easier.

                  Transition:

                  We have tried to make this smooth.

                  0) The best approach is to first bring your rc.conf up-to-date according to the recommendations in "man rc.conf". It should essentially only contain your DAEMONS array (and a few other things, depending on your setup, see manpage for details). This will work both with initscripts and systemd so it is safe to do ahead of time, and make sure everything works as it should.

                  1) Install systemd, but you do not need to remove initscripts. You can now chose between the two at runtime (by adding init=/bin/systemd to your kernel commandline). If you do this systemd will keep respecting rc.conf and use rc scripts if systemd unit files can not be found.

                  2) Then you can move your system (hopefully seamlessly) over to a native systemd configuration: do (0) if you did not already, then find the corresponding systemd service file for every daemon in your daemons array and enable it using "systemctl enable <daemon>.service". Once this is done rc.conf is not needed by systemd at all anymore. Go through rc.local and rc.local.shutdown and turn them into service files (or, if you intend to keep them as they are, copy /usr/lib/systemd/system/rc-local{,.shutdown}.service to /etc/systemd/system/).

                  3) Once the above works ok, and you are confident that you don't need to revert to initscripts, then you can install systemd-sysvcompat, which will conflict (and hence remove) sysvinit+initscripts (and pacsave rc.conf, rc.local and rc.local.shutdown). You can now also remove init=/bin/systemd from your kernel commandline as /sbin/init will now be a symlink to systemd.

                  Benefits:

                  I have spent too much time arguing against the perceived deficiencies of systemd (such as: "it is not written in bash", "it was started by Lennart Poettering", "I don't like the (optional) on-disk format of the journal", "it uses dbus", "systemd's PID1 does more and is bigger than sysvinit's PID1", "I think there might be this other project that possibly is doing something similar. I don't really know anything about it, but I'm pretty sure it is better than systemd" and I'm sure there are many more). I strongly believe that 1) all of these perceived deficiencies are not deficiencies, but are actually benefits 2) even if I'm wrong, these things are not hugely important. So, with that out of the way: let's ignore all of those old boring arguments and I'll outline a few things that I find awesome about systemd, and why I think we should all be very excited about soon being able to use it. In no particular order:

                  0) it is hotplug capable: systemd assumes that all resources may appear and dissapear at any time. If you plug in your external harddrive after systemd has booted, it will be fsck'ed and mounted correctly. This is unlike initscripts which relies on all disks being enumerated and ready when it starts fsck, and then it relies on fsck of all disks being finished before it starts mounting any of them. Hotplug is important, not only because it is convenient to be able to insert/remove hardware while the system is running, but also because that's how the linux kernel does boot: every device appears to be "hotplugged" as the kernel becomes aware of it, so with a very fast boot we can no longer assume that all devices are ready and waiting for us when we need them (even if they were plugged in when the computer started). In reality this is often not a problem, but if you ever had your rootfs on an external USB harddrive you might have experienced problems (and as things become faster and faster more problems like this will crop up).

                  1) we can know the state of the system: systemd keeps track of all daemons, and all processes that are started, and who owns what, and when something fails, etc. Also, using the (awesome) journal all syslog() entries and writes to stdout/stderr by all processes are captured by systemd. These are stored with enough meta-data so that you can very easily retrieve say "all entries from a certain service/binary/pid" or "all entries written by the kernel regarding a given device", etc. In addition to logging this information, and showing it to you, systemd will allow you to specify (easily) what to do in a wide range of possible error-scenarios: "a service shuts down normally/with an error/ on a signa" or "a service has not sent its watchdog signal in the designated time" or "a service has shutdown with an error 10 times in the last half hour". The recent addition of hardware watchdog support also allows you to say "restart the machine if systemd itself is not responding".

                  2) it is modular: all of what is now rc.sysinit is split out into many independent services, each of which is well documented and easy to understand. I.e., if you don't like how systemd e.g. does it's fstab handling, then you can write your own little helper (in bash if you wish) to replace the official one. Doing this in the old initscripts is much harder because 1) it is not so clear which parts of rc.sysinit are dependent on eachother 2) any changes you do you'll have to merge on every update.

                  3) it allows dbus/udev to go back to doing the task they are meant to do: both udev and dbus are currently (mis)-used to start daemons/long-running services on demand. In the case of dbus this is by design, but in the case of udev it is not. Either way, it is not what those daemons were built to do, so in keeping with the UNIX principle of one task per daemon, it is great that we can now let systemd (whose job it is to manage daemons) take this over. That is, udev and dbus can both signal systemd to start a certain daemon, and it will behave like if it was started in any other way (you have the logs, status etc). One problem that this solves is the inherent race-condition in some daemons (I think bluetoothd was guilty of this at some point) allowing both being started as soon as possible on boot (say by putting it in DAEMONS), and to be started on-demand by dbus. Systemd makes sure that both these things can happen, and if they do happen at the same time you will only end up with one instance of the daemon as expected.

                  4) we can reduce the number of explicit ordering dependencies between daemons (this might require changes to the daemons in question): using socket activation, automounting and dbus activation we are able to forget about stuff like "dbus must be running before we start avahi" or "yp-bind must be started after networkmanager". systemd can create sockets early on, before any daemons are started, and then pass the socket to the relevant daemon when it gets around to starting it. This means that anything can connect to anything else, without caring about whether or not the other daemon has finished starting yet. The kernel will simply buffer the requests whilst we wait and deliver them when it can. Notice that this does not actually remove any dependencies (so if there are circular deps, they will still be there), but it means we no longer have to specify them, nor worry about races between them.

                  5) we get a lot of security/sandboxing features for free: you can simply add some configuration options to the unit files in question to isolate them from the system in various ways. This was of course also possible before, but it required you to write lots of boilerplate code in every rc script, and this kind of things are very error prone, and best reviewed by people who know about this stuff.

                  6) systemd service files can (and hopefully will!) be written and distributed upstream: rather than every distro writing their own rc script (with their own set of trivial bugs and misunderstandings) the people who know the software the best (upstream) possibly with some input from the people who know the init system the best (systemd devs) can write "perfect" services that should just work everywhere. We have seen some of this already, and I think it is hugely benefitial. Even for distros who don't pick up systemd yet, this will allow them to at least have an idea oh how the software is meant to be initialized.

                  7) systemd is a cross-distro project: every major and many, many minor distros have had people contributing to systemd. last i heard even two debian devs have commit access to the repo, among many others. systemd upstream is very accommodating of different needs and different use-cases (as long as they are presented on technical grounds) and have been a pleasure to work with so far. We are getting the joint experience of a lot of people/projects who have worked on different init systems for a long time, I think this is one of the most important "features" one could have.

                  8) logind will finally deliver on what consolekit was supposed to do: we can now track user sessions and seats, assign permissions to resources on-the-fly etc. This should be the topic of a separate message, as it is too much to get into. Suffice it to say that I'm very happy that we are finally getting these features working as they should.

                  9) systemd is fast: Or is it really? Some claim there is no difference compared with initscripts, a very few claim it is slower, the vast majority claim it is a lot faster. I claim that I really don't care. The above points (which is just what I could think of at the top of my head, so not exhaustive by any means) would hopefully convince you that systemd is the right choice irrespective of its speed, and once you try it out you might be in for a pleasant surprise ;-)
                  Originally posted by Naib View Post
                  systemd right now is a trainwreck, they are blaming the kernel for effects they have created, they are coming up with arse about face "workarounds" for a process they broke which was fine before
                  It's a problem that existed in udev even before the merge with systemd. Also it's not "they" but rather just Kay (if I'm not mistaken).

                  Originally posted by Naib View Post
                  They want/need mtab to be a symlink
                  From the mailing list topic you posted:
                  Crossflash: Debian pretty much always had it a symlink IIRC; and on
                  Solaris, mtab was a similarly special file - not that either of the two
                  use systemd! The extra vfsmounts certainly were not a problem to them.
                  Last edited by Teho; 08 October 2012, 04:43 PM.

                  Comment


                  • #10
                    Also tomegun wrote in the Mailing list or in the Forums that arch is not affected by the udev bug/regression/whatever.

                    I believe that arch will also use systemd for its user session also but thats quite a distant plan.

                    Anyway there is always slackware for the "change is bad" beardnecks.
                    Last edited by 89c51; 08 October 2012, 04:49 PM.

                    Comment

                    Working...
                    X