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.
God damn it... It's not systemD or SystemD or Systemd, etc., etc. - it's always written as "systemd" (all lower case).
@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 parent
Last edited by Ericg; 05-07-2013 at 09:23 PM.
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:
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
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
Last edited by Nuc!eoN; 05-07-2013 at 10:13 PM.
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.
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.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."