Announcement

Collapse
No announcement yet.

Systemd 203 Is A Good Release, Brings New Features

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

  • #21
    Originally posted by Nuc!eoN View Post
    Sorry but this just isn't true. The "upgrade" to systemd rather broke many things. Please don't spread FUD.
    SystemD _was_ an upgrade. I'll yield that it implemented breaking changes, but... 1) You can write your own service files, and 2) you'd be hard pressed to find a better init system for Arch.

    Comment


    • #22
      God damn it... It's not systemD or SystemD or Systemd, etc., etc. - it's always written as "systemd" (all lower case).

      Comment


      • #23
        Originally posted by bobwya View Post
        God damn it... It's not systemD or SystemD or Systemd, etc., etc. - it's always written as "systemd" (all lower case).
        Its "systemd" in all cases EXCEPT if your language demands-- as English does-- that the first letter of a word be capitalized if it starts a sentence, then LP says its okay to call it Systemd =P
        All opinions are my own not those of my employer if you know who they are.

        Comment


        • #24
          Originally posted by Akka View Post
          Or not again be able to trust your processes really is dead when you stopped a service.
          Unfortunately this does apply for systemd, because services can be pulled in by other apps (without your knowledge). Masking works mostly however.

          @eric: SLiM for instance, is still seriously broken.

          Also IMHO systemd should trust it's user more and do less "auto-magic" (services enabled without your knowledge etc), for most distros that's ok, but it doesn't fit into Arch. Besides I consider systemd pulling in much redundancy and unneeded complexity. Not quite the unix philosophy....
          Initscripts seemed to do the job for me... systemd reminds me of the pulseaudio hype.

          But that's just my humble opinion, and I might be wrong in some things. I'm sure eric will blow off all of my arguments :P

          Comment


          • #25
            Originally posted by Nuc!eoN View Post
            Unfortunately this does apply for systemd, because services can be pulled in by other apps (without your knowledge). Masking works mostly however.

            @eric: SLiM for instance, is still seriously broken.

            Also IMHO systemd should trust it's user more and do less "auto-magic" (services enabled without your knowledge etc), for most distros that's ok, but it doesn't fit into Arch. Besides I consider systemd pulling in much redundancy and unneeded complexity. Not quite the unix philosophy....
            Initscripts seemed to do the job for me... systemd reminds me of the pulseaudio hype.

            But that's just my humble opinion, and I might be wrong in some things. I'm sure eric will blow off all of my arguments :P
            Hey now, I'm a systemd fan but I'm not a fanboy or unreasonable lol. Good to know that SLiM is still broken though, I stopped using it a while back and moved onto LightDM, so I didnt know it had been broken. Any idea of whats breaking specifically? Is it PAM and not playing nicely with logind or what?

            I will agree that auto-enabling services is less KISS and minimal than Arch usually does, but I kind of feel like its the same argument that got used about the new auto keyword in C++...

            Before auto, if you wrongly typed a variable, the compiler would scream at you "I know this is EXACTLY what you should have typed, now go be a good boy and fix it." Where the auto keyword now comes in and says "I know this is EXACTLY what it should be, and now it is." Systemd is the same way, Many times I had services fail to start on Arch because my daemon's array was out of order / in the wrong order for that particular daemon and its kind of like: "I know EXACTLY what I need to run, but I'm not gonna do it. You need to do it."

            Which is awesome in regards to "Well this way you know exactly whats running on your system." But...why dont we as a community have that same attitude towards package managers? If systemd is solving the dependency issue for us during boot, and some people are against that, why arent they against package managers auto-handling package dependencies this way you know EXACTLY what is on your system? (I know Slackware does that, and i fully expect slackware to never adopt systemd for this SAME reason)

            Redundancy I, and LP and Kai have all talked to death whether in official capacities or for me: here on these forums. Complexity I agree with, to an extent. But I believe the modular nature that systemd is developed in, helps that issue.

            EDIT: Regarding your response to Akka, I THINK he was referring to the issue of "Processes cant double-fork and thereby escape their init scripts." Which is the whole thing around systemd using cgroups to track processes instead of just PID and parent
            Last edited by Ericg; 07 May 2013, 08:23 PM.
            All opinions are my own not those of my employer if you know who they are.

            Comment


            • #26
              Originally posted by stqn View Post
              That sounded promising, but I?m not launching sshfs from fstab and this:
              $ sshfs 192.168.0.2:/media/disk /mnt/computer -o _netdev
              returns:
              fuse: unknown option `_netdev'

              I?ve searched the web some more for this _netdev option but without much success so far.
              `_netdev' is useless outside of fstab anyway. It's meant to be parsed by init implementations during bootup/shutdown only. For example, systemd uses it to order network mounts after network.target. AFAIK the kernel never uses it at all.

              Also, systemd currently has no way of knowing that your (manually mounted) sshfs is a network file system. So, even though systemd will create a .mount-unit in /run, that unit won't be configured with After=network.target. Consequently, on shutdown, systemd might just stop the network before stopping sshfs and then apply its standard timeout (~90 seconds) on your sshfs mounts before forcibly killing them.

              Another problem is the fact that systemd does not (yet?) support explicit ordering of services with ``Type=oneshot'' during shutdown. So the intuitive approach to writing a unit that terminates sshfs won't work (i.e. Type=oneshot, WantedBy=shutdown.target, After=network.target, ...).

              There was some talk about all that stuff on systemd-devel some time ago and I seem to recall that fixing those issues is on the todo list. Long story short: to achieve proper ordering, you need a dummy service that's ordered after network.target and gets started on bootup and stopped again on shutdown. You could try something like this:

              /etc/systemd/system/killsshfs.service:

              Code:
              [Unit]
              After=network.target
              
              [Service]
              RemainAfterExit=yes
              ExecStart=-/bin/true
              ExecStop=-/usr/bin/pkill sshfs
              
              [Install]
              WantedBy=multi-user.target

              Code:
              # systemctl enable killsshfs.service

              Comment


              • #27
                Originally posted by Ericg View Post
                Good to know that SLiM is still broken though, I stopped using it a while back and moved onto LightDM, so I didnt know it had been broken. Any idea of whats breaking specifically? Is it PAM and not playing nicely with logind or what?
                Yeah, a positive effect of SLiM's current state is that it forced me to look out for some alternative, in my case SDDM which I pretty like now (won't switch) :P
                SLiM kind of works but, even I, loose my patience someday and think "FFS why do I need to deal with this shit, everday !?". Especially the logout process hangs, but also shutdown/restart etc, it inevitably will drive you nuts. Here's the unresolved bugreport: https://bugs.archlinux.org/task/3238...=2&string=slim

                Originally posted by Ericg View Post
                Redundancy I, and LP and Kai have all talked to death whether in official capacities or for me: here on these forums.
                is it just me smoked some grass or is this sentence seriously broken?
                Originally posted by Ericg View Post
                Complexity I agree with, to an extent. But I believe the modular nature that systemd is developed in, helps that issue.
                First of all, I'm not an enemy of systemd, there's just some things I am not totally in favor. In other words: I do like it's innovations. Maybe, just like Gentoo folks did with udev, the Arch devs should fork systemd, aiming towards a light-weight init-system that simply does it's job but in a modern and efficient way (just like SDDM wonderfully replaces SLiM with the latest technology, but still being light weight).
                Last edited by Nuc!eoN; 07 May 2013, 09:13 PM.

                Comment


                • #28
                  Originally posted by Nuc!eoN View Post
                  Yeah, a positive effect of SLiM's current state was that it forced me to use some alternative, in my case SDDM which I pretty like now (won't switch) :P
                  SLiM kind of works but, even I, loose my patience someday and think "FFS why do I even need to deal with this shit !?". Especially the logout process hangs, but also shutdown/restart etc, it inevitably will drive you nuts. Here's the unresolved bugreport: https://bugs.archlinux.org/task/3238...=2&string=slim
                  Interesting, I hadn't seen that bug. I'll have to keep that in mind. Is SDDM working properly now? Last time i tried (from git aur package) it loaded properly, but when you logged in it would just drop you back at the login screen.

                  Originally posted by Nuc!eoN View Post
                  is it just me smoked some grass or is this sentence seriously broken?
                  It was off a little :P It should say

                  Redundancy... I, and LP, and Kai have all talked to death. Whether in official capacities (for Kai and LP) or here on these forums, for myself.

                  First of all, I'm not an enemy of systemd, there's just some things I am not totally in favor. In other words: I do like it's innovations. Maybe, just like Gentoo folks did with udev, the Arch devs should fork systemd, aiming towards a light-weight init-system that simply does it's job but in a modern and efficient way (just like SDDM wonderfully replaces SLiM with the latest technology, but still being light weight).
                  I didn't say you were any an enemy (Sorry if the reply came off hostile). But I'm also not sure if forking is the proper way to go. Eudev was mostly created because Gentoo freaked out over the fact that udev was in the systemd source tree... you can still run just udev, you dont HAVE to have systemd to run udev. And I know LP has said that he looks forward to the day that they can drop non-systemd support from udev.... which quite frankly is fine. He's hoping his project achieves world domination, theres nothing wrong with that.

                  If you want a lightweight init system (systemd), all you have to do is pass "--disable" to systemd during compile and strip away everything you want. You can cut systemd down to practically nothing if you really want something minimal and lightweight. Also I'll point to Martin Graesslin's blog...what does lightweight even mean? Systemd is light on resources, scales perfectly from 1 core to 100 cores, its very speedy in basically everything it does. If you mean "it doesnt have a lot of features and does the bare minimal" then I'd have to say that "minimal" is the proper word you'd be looking for rather than "lightweight."
                  All opinions are my own not those of my employer if you know who they are.

                  Comment


                  • #29
                    Originally posted by ceage View Post
                    /etc/systemd/system/killsshfs.service:

                    Code:
                    [Unit]
                    After=network.target
                    
                    [Service]
                    RemainAfterExit=yes
                    ExecStart=-/bin/true
                    ExecStop=-/usr/bin/pkill sshfs
                    
                    [Install]
                    WantedBy=multi-user.target

                    Code:
                    # systemctl enable killsshfs.service
                    Thanks a lot ceage, it?s working!

                    Comment


                    • #30
                      Originally posted by stqn View Post
                      Thanks a lot ceage, it?s working!
                      Hey, stqn, I meant to ask you this earlier.... why aren't you using fstab for the sshfs mount? It would let you do _netdev (and not have to use that slightly-hackish unit file) and if you didnt want it mounted automatically then adding noauto should (in theory) let you keep the benefits of _netdev without it being done 24/7
                      All opinions are my own not those of my employer if you know who they are.

                      Comment

                      Working...
                      X