Originally posted by Nuc!eoN
View Post
Announcement
Collapse
No announcement yet.
Systemd 203 Is A Good Release, Brings New Features
Collapse
X
-
Originally posted by bobwya View PostGod damn it... It's not systemD or SystemD or Systemd, etc., etc. - it's always written as "systemd" (all lower case).All opinions are my own not those of my employer if you know who they are.
Comment
-
Originally posted by Akka View PostOr not again be able to trust your processes really is dead when you stopped a service.
@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
-
Originally posted by Nuc!eoN View PostUnfortunately 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
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 parentLast 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
-
Originally posted by stqn View PostThat 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.
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
-
Originally posted by Ericg View PostGood 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?
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 PostRedundancy I, and LP and Kai have all talked to death whether in official capacities or for me: here on these forums.
Originally posted by Ericg View PostComplexity I agree with, to an extent. But I believe the modular nature that systemd is developed in, helps that issue.Last edited by Nuc!eoN; 07 May 2013, 09:13 PM.
Comment
-
Originally posted by Nuc!eoN View PostYeah, 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
Originally posted by Nuc!eoN View Postis it just me smoked some grass or is this sentence seriously broken?
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).
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
-
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
Comment
-
Originally posted by stqn View PostThanks a lot ceage, it?s working!All opinions are my own not those of my employer if you know who they are.
Comment
Comment