Page 3 of 9 FirstFirst 12345 ... LastLast
Results 21 to 30 of 84

Thread: Lennart Poettering Takes To Battling Systemd Myths

  1. #21
    Join Date
    Oct 2011
    Posts
    56

    Default 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:
    https://forums.gentoo.org/viewtopic-...6.html#7229136

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

  2. #22
    Join Date
    Oct 2009
    Posts
    59

    Default

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

  3. #23
    Join Date
    Jan 2013
    Posts
    1,103

    Default

    Quote Originally Posted by ulenrich View Post
    The really heavy obstacles in our world are beliefs:

    , this a long time Gentoo advocate at:
    https://forums.gentoo.org/viewtopic-...6.html#7229136

    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.

  4. #24
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,858

    Default

    Quote 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.*


    Quote 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

  5. #25
    Join Date
    Oct 2009
    Posts
    59

    Default

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

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

    Quote 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; 01-26-2013 at 10:59 PM.

  6. #26
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,858

    Default

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

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

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

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

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

  7. #27
    Join Date
    Sep 2011
    Posts
    62

    Default

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

  8. #28
    Join Date
    Nov 2012
    Posts
    593

    Default

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

  9. #29
    Join Date
    Oct 2009
    Posts
    845

    Default

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

  10. #30
    Join Date
    Sep 2011
    Posts
    154

    Default

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •