Announcement

Collapse
No announcement yet.

Lennart Poettering Takes To Battling Systemd Myths

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

  • #21
    heavy obstacle is belief

    The really heavy obstacles in our world are beliefs:

    RANT! Someone is trying to turn Linux into Windows! They're trying to turn it into "Just Works (TM)", ...
    , this a long time Gentoo advocate at:


    Therfore true Linux/Unix is: It has to just NOT work!
    Otherwise it is a conspiracy ....

    Comment


    • #22
      Originally posted by Ericg View Post
      Debian wants to be able to swap out kernels so theyre stuck with sysV. If and when systemd removes non-systemd support from udev they'll probably switch to eudev.

      Gentoo lets you swap out components anyway. The users who want to use systemd will use mainline udev. The users who dont want systemd will use eudev.
      As a note Gentoo also supports other kernels like BSD. It also supports prefixes (mostly) and a number of other crazy setups. so add gentoo to debian in the first comment.

      Is there a supported way to build and install only udev? how about only systemd? only journal? On a gentoo system all three will be seperate compiles and installs. Having to always build all three will make it take longer to install, require more disk space, and generally be annoying.


      On to systemd questions; Can I write my own init file in plaintext with gvim for systemd? Is there documentation on how to build these. I like the well documented gentoo setup for this reason. It's very easy to write one if i want to, and I have in the past.

      Comment


      • #23
        Originally posted by ulenrich View Post
        The really heavy obstacles in our world are beliefs:

        , this a long time Gentoo advocate at:


        Therfore true Linux/Unix is: It has to just NOT work!
        Otherwise it is a conspiracy ....
        May be you shouldn't rip that quote out of context, so that you can present the actual meaning, which is quite different from your conclusion:
        Oddly enough the clueless noob who doesn't configure anything will be better off, because he/she won't have things like "config_eth0=..." sitting anywhere to become stale.

        RANT! Someone is trying to turn Linux into Windows! They're trying to turn it into "Just Works (TM)", except when it doesn't, then abandon all hope, because we're removed, hidden, obscured, or obfuscated the knobs that allow you to make it work. Your choices are to be a complete clueless noob, or to become a near-developer - the self-educated hacker is out of luck.

        Comment


        • #24
          Originally posted by cynyr View Post
          Is there a supported way to build and install only udev? how about only systemd? only journal? On a gentoo system all three will be seperate compiles and installs. Having to always build all three will make it take longer to install, require more disk space, and generally be annoying.
          Building stock systemd pulls in hard dependencies on udev, and journal and by default pulls in some of the things I mentioned in an earlier post, along with others. The only things you HAVE to build when you build systemd is systemd, udev and journal, all else is optional. (Hostname / timezone / hardware clock / cron / etc)

          Journal depends on systemd so they cannot be decoupled.
          Udev CAN be decoupled from systemd the only weird thing is you have to pull in all of the systemd sources to do it since they are in the same tree. So you get ALL of the systemd sources but when you actually compile it, you can tell it "I only want udev to be compiled" and when its done, you'll only have udev.*


          Originally posted by cynyr View Post
          On to systemd questions; Can I write my own init file in plaintext with gvim for systemd? Is there documentation on how to build these. I like the well documented gentoo setup for this reason. It's very easy to write one if i want to, and I have in the past.
          I'm ASSUMING (Correct me if im wrong) when you say "init file" you mean the files that typically resided in /etc/init.d/ or gentoo equiv, correct? (Arch's equiv was /etc/rc.d/)

          in the systemd world those are called ".service" files. And yes they are written in plaintext.

          The defaults (distro package provided ones) are stored in /usr/lib/systemd/system/
          If you want to modify or override anything provided by the distro then you place them /etc/systemd/systemctl and they will take priority over the ones in /usr/lib. Packages supply their own .service files, systemd does not provide them itself.

          the Arch wiki has a great section where some non-default .service files are done for programs that dont have a native systemd service file: https://wiki.archlinux.org/index.php/Systemd/Services

          Below this is a shortrun through an example .service file since I got the impression you hadnt looked at one before. if you have, sorry >_> but its a good read for anyone else who has not since they are so simple.

          [Unit]
          Description=Adsuck daemon
          After=network.target

          [Service]
          Type=forking
          ExecStart=/usr/sbin/adsuck -l 127.0.0.1 -c /var/adsuck -f /resolv.conf /hosts -r /filter
          ExecStartPost=/bin/sh -c "echo 'nameserver 127.0.0.1' > /etc/resolv.conf"
          ExecStop=/bin/kill $MAINPID
          ExecStopPost=/bin/sh -c "cp /var/adsuck/resolv.conf /etc/resolv.conf"
          ExecReload=/bin/kill -HUP $MAINPID ; /bin/kill -USR1 $MAINPID

          [Install]
          WantedBy=multi-user.target
          Description: is what appears when someone looks at the daemon through systemctl (systemctl status adsuck)
          After: Tells systemd to only start this after the network has been started (not necessarily established, but just the daemon responsible for the network has been successfully start
          Type: tells systemd what to watch for. in the sysV world a process can be lost if it double-forks, thereby seperating it from its parent process. In the systemd world that isnt allowed. They can still fork as many times as they want, but systemd will always know where it is and what its process tree (including parent) looks like
          ExecStart: tells systemd what command to run when the service file is passed "start" (systemctl start adsuck)
          ExecStartPost: tells systemd what commands to run AFTER the service has been successfully started.
          ExecStop: tells systemd what commands to run when the service is passed the "stop" command (systemctl stop adsuck)
          ExecStopPost: tells systemd what commands to run when the service reports a clean exit. Eg: cleanup commands.
          ExecReload: tells systemd what to do in the event the service wants to be stopped and then restarted immediately (systemctl restart adsuck)
          WantedBy: tells systemd what level in the init tree this should go into. Systemd has a concept of runlevels, they jsut aren't called that.

          single-user.target is runlevel 1 from sysV
          mutli-user.target is runlevel 3 from sysV
          graphical.target is runlevel 5 from sysV
          reboot.target is runlevel 7(?) from sysV

          Graphical.target pulls in anything linked against multi-user.target which in turn pulls in anything linked against single-user.target. The rule of thing is lowest level necessary. Adsuck is a network daemon and doesnt have or atleast does not require a GUI, therefore it goes against multi-user.target. But kdm or gdm DO require a gui so they go against graphical.target


          And so ends what was probably my longest post on these forums, ever XD
          All opinions are my own not those of my employer if you know who they are.

          Comment


          • #25
            Originally posted by Ericg View Post
            Journal depends on systemd so they cannot be decoupled.
            Udev CAN be decoupled from systemd the only weird thing is you have to pull in all of the systemd sources to do it since they are in the same tree. So you get ALL of the systemd sources but when you actually compile it, you can tell it "I only want udev to be compiled" and when its done, you'll only have udev.*
            Is this supported such as "./configure --only-udev && make && make install"? If not it makes it a huge pain to get just one part.

            Originally posted by Ericg View Post
            I'm ASSUMING (Correct me if im wrong) when you say "init file" you mean the files that typically resided in /etc/init.d/ or gentoo equiv, correct? (Arch's equiv was /etc/rc.d/)
            Yep that is what I mean.

            Originally posted by Ericg View Post
            The defaults (distro package provided ones) are stored in /usr/lib/systemd/system/
            If you want to modify or override anything provided by the distro then you place them /etc/systemd/systemctl and they will take priority over the ones in /usr/lib. Packages supply their own .service files, systemd does not provide them itself.

            the Arch wiki has a great section where some non-default .service files are done for programs that dont have a native systemd service file: https://wiki.archlinux.org/index.php/Systemd/Services

            Below this is a shortrun through an example .service file since I got the impression you hadnt looked at one before. if you have, sorry >_> but its a good read for anyone else who has not since they are so simple.
            Nope I haven't looked at them at all, all my computers boot great (mostly) right now, and mucking with semi-supported inits isn't all that interesting on live systems, and low priority for playing with in a VM.

            One of the things I really like in gentoo is the pre_up and post_up functions for the networking init scripts. This allows things like setting up ssh tunnels when not on a particular wifi network, or setting link speeds before trying to get an IP address (to work around a busted network card I had at one point). It looks like execstartpost exists, and I'll assume that a execstartpre also does.

            poking around arch's wiki for systemd I stumbled into another question, is there a way to read the log for a computer that I have a non-bootable system on? Normally I'd yank the HDD and mount the drive, and read /var/log/messages however I like. even if there was some minor corruption of that file it's likely something could still be read.

            TBH I have a bit of knee jerk reaction to LPs stuff and have a tenancy to let it settle out for a while before I even try it out. For the most part it seems like LP lifted some of the things I like from openRC and added a few more interesting looking things the inherent directive or .path services for example. However a lot of the stuff sunning on my server seems like I would need to write .service files for at this point in time, like mediatomb and lighttpd. Though those may be provided by systemd itself.

            Maybe one of these day I'll get around to playing with it in a VM.
            Last edited by cynyr; 26 January 2013, 11:59 PM.

            Comment


            • #26
              Originally posted by cynyr View Post
              Is this supported such as "./configure --only-udev && make && make install"? If not it makes it a huge pain to get just one part.
              Don't know the exact command for it off the top of my head, just remember that there IS a way.

              Originally posted by cynyr View Post
              Nope I haven't looked at them at all, all my computers boot great (mostly) right now, and mucking with semi-supported inits isn't all that interesting on live systems, and low priority for playing with in a VM.
              Semi-supported is a bit of jump. Especially considering you can pass "init=/sbin/systemd" as a kernel parameter at boot and if you hate it / it breaks something you can get back to OpenRC by just removing that parameter. I run systemd on every linux install I have (whether via Fedora or through my home server & laptop--both running Arch) and everything works flawlessly.

              Originally posted by cynyr View Post
              One of the things I really like in gentoo is the pre_up and post_up functions for the networking init scripts. This allows things like setting up ssh tunnels when not on a particular wifi network, or setting link speeds before trying to get an IP address (to work around a busted network card I had at one point). It looks like execstartpost exists, and I'll assume that a execstartpre also does.
              Most likely, the systemd documentation has a listing of every single configuration option .service files support, and they are adding more all the time.

              Originally posted by cynyr View Post
              poking around arch's wiki for systemd I stumbled into another question, is there a way to read the log for a computer that I have a non-bootable system on? Normally I'd yank the HDD and mount the drive, and read /var/log/messages however I like. even if there was some minor corruption of that file it's likely something could still be read.
              Unsure, I know there's a way to export journal's binary logs into a plaintext format. But I am unsure (off the top of my head) if theres a way to have an external journal binary read a mounted system's journals. But as I've said before in this thread: journal doesnt take exclusive access to logs. I've got syslog-ng and journal both running on this laptop simultaneously. If for some reason journal's logs get screwed over, or they arent enough, I can just cd into /var/log and read the plaintext ones that syslog caught.

              Logging in systemd goes process does a log event -> passes it to systemd -> systemd passes the information from the process (plus meta information from systemd, like the pid and user and stuff like that) to journal -> journal creates its own log -> systemd then repasses the log event to syslog (if its available, eg: installed and running) -> syslog does traditional log.

              Originally posted by cynyr View Post
              TBH I have a bit of knee jerk reaction to LPs stuff and have a tenancy to let it settle out for a while before I even try it out. For the most part it seems like LP lifted some of the things I like from openRC and added a few more interesting looking things the inherent directive or .path services for example. However a lot of the stuff sunning on my server seems like I would need to write .service files for at this point in time, like mediatomb and lighttpd. Though those may be provided by systemd itself.
              I had a bit of a reaction to LP's stuff at first too but nothing's perfect. Pulse had its problems, but they got fixed. NetworkManager wasn't perfect (still missing Bridging support though I think thats coming in the next version, or atleast the groundwork is), and systemd once upon a time would fail to boot every once and awhile. Bugs were found. Bugs were fixed. Projects improved. I can very confidently say now that on all of my arch machines, with varying hardware, I have zero second-thoughts about installing systemd + Pulseaudio + Networkmanager + Avahi. They just ARE the standard to me now because I know they DO work.

              Btw, out of curiosity I just installed lighttpd and mediatomb on this laptop from Arch's repos. lighttpd came with a .service file, Mediatomb did not. Just so ya know. And Arch typically doesnt add files to packages. Even during the initial move to systemd all additional .service files were kept in a seperate package, they weren't added into the specific applications files so that means lighttpd is shipping a .service file as part of upstream.

              MOST programs DO ship .service files now because RHEL 7 (and by extension CentOS) will be systemd, Arch is systemd, Fedora is systemd.

              Systemd can also parse init.d/rc.d scripts so theres that OR you could set it up where the .service file for your app actually just calls your custom written rc.d/init.d script. Make a script for mediatomb, drop it in /etc/init.d/ then just whip up a quick mediatomb.service file, drop it in /etc/systemd/system. have:

              ExecStart=/etc/init.d/mediatomb start
              ExecStop=/etc/init.d/mediatomb stop

              this way you dont have to really mix and match init systems. a quick "systemctl enable mediatomb" will tell it to start on boot. and a "systemctl start mediatomb" will run ExecStart. Because its in /etc/systemd/system you dont have to worry about it ever being overwritten. The only problem would be if mediatomb did ever ship a default .service file, yours would automatically override it because they have the same name. So you might want to make it be "my-mediatomb.service" or something like that.
              All opinions are my own not those of my employer if you know who they are.

              Comment


              • #27
                "systemd is linux only" "its not our fault bsd devs dont make it work on bsd!"

                well, proves the point lol.

                also systemd's biggest dep is indeed, dbus.

                likewise, compared to shell scripts the flexibility goes down and the complexity goes up.. obviously, there isn't much you can do about that.

                Comment


                • #28
                  Originally posted by balouba View Post
                  likewise, compared to shell scripts the flexibility goes down and the complexity goes up.. obviously, there isn't much you can do about that.
                  Yeah, try doing the same what systemd does using shell scripts. Shell scripts are a complex nightmare. They're also slow as hell and don't even tell me about their "flexibility" - try using the same scripts on few distros.

                  Comment


                  • #29
                    Originally posted by Pawlerson View Post
                    Yeah, try doing the same what systemd does using shell scripts. Shell scripts are a complex nightmare. They're also slow as hell and don't even tell me about their "flexibility" - try using the same scripts on few distros.
                    Yes, while I've found init scripts to be conceptually easy to grasp, everything I've read about implementing and maintaining them hints at it being very complex and error-prone.

                    Comment


                    • #30
                      Originally posted by balouba View Post
                      "systemd is linux only" "its not our fault bsd devs dont make it work on bsd!"

                      well, proves the point lol.

                      also systemd's biggest dep is indeed, dbus.

                      likewise, compared to shell scripts the flexibility goes down and the complexity goes up.. obviously, there isn't much you can do about that.
                      This


                      SystemD is to shell scripts what the Windows registry is to plain text configs.

                      Comment

                      Working...
                      X