Announcement

Collapse
No announcement yet.

Systemd 203 Is A Good Release, Brings New Features

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

  • #16
    Originally posted by stqn View Post
    Actually, the Arch Linux devs chose systemd and itís nearly impossible to use something else now. (Everything is possible but all official packages are made for systemd.)

    I hope the systemd devs will stop breaking and changing things soon. Still haven't found how to make it not hang at shutdown if I don't manually unmount sshfs before.
    I didn't mean that Arch Linux as project itself and it's devs chose systemd over something else I was talking about it's modular nature where users can choose what they want.And I'm getting worried how quickly people started to like systemd just because it has everything packaged in.

    Comment


    • #17
      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.
      What did it break for you Nucleon? Because I was on systemd from the moment it packaged in Arch's repos and never had any problems. When I got a new computer I downloaded the iso that happened to be the month before the move to systemd, when systemd hit i upgraded, and nothing broke. Everything kept on just as it had always.

      Comment


      • #18
        Originally posted by kUrb1a View Post
        I didn't mean that Arch Linux as project itself and it's devs chose systemd over something else I was talking about it's modular nature where users can choose what they want.
        Yes thatís what I understood, and Iím telling you, no, Arch Linux users donít get to choose their init system, unless theyíre good enough and have enough time to fight against the tide. The only supported init system in Arch is systemd.

        Comment


        • #19
          Originally posted by Honton View Post
          Life is limited to ~100 years. Why would anyone waste a minute fighting against a modern, proven, and well maintained init system?
          Are you saying sysV was modern, proven and well maintained or that systemd is modern, proven and well maintained? Having a hard time following your guy's conversation...

          Comment


          • #20
            Originally posted by stqn View Post
            Yes thatís what I understood, and Iím telling you, no, Arch Linux users donít get to choose their init system, unless theyíre good enough and have enough time to fight against the tide. The only supported init system in Arch is systemd.
            My English is bad but I don't think that was what he meant. Systemd has a modular architecture and you can choose how much of it you want with build flags. You don't need to build everything.
            But I think everything is pretty nice. After used systemd a time, I have no desire to use a old primitive logging again. Or not again be able to trust your processes really is dead when you stopped a service.

            Comment


            • #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

                  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; 05-07-2013, 08:23 PM.

                      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; 05-07-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."

                            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

                                Comment

                                Working...
                                X