Major distros who are using SysV?
Gentoo, Slackware, Debian (Im leaving RHEL + its clones out of this because RHEL7 uses systemd)
Major distros using Upstart?
Ubuntu, (+derivatives, but basically Ubuntu.)
Everyone else? systemd
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.
Slackware.... who the hell knows what those guys will do.
Ubuntu...I really hope will adopt systemd but I'm not holding my breath. They're basically in the same boat as debian/gentoo. If they dont want to use systemd they'll use eudev, if they do want to use systemd then its a non-issue.
If you tie systemd to udev, you're effectively forcing everybody who uses the Linux kernel to use systemd. Since there is a non-empty set of people who are interested in running Linux without running systemd (full disclosure: I'm one of them), it was no surprise that when udev and systemd were merged some voices were heard of people fearing that they would be pushed into using systemd.
On that occasion udev and systemd developers reassured everybody thay "nothing would change", as it was merely a matter of "sharing code". It turned out that no, in fact things would change, as udev changed in an incompatible way when it was merged; another change was that now you have to build the full systemd package in order to obtain the udev binary (which also changes name into "systemd-udev", and gets moved to another location upon installation) and manually rip it out of the built package. Building the systemd package has many more requirements than udev, and some of them can't be cleanly cross-compiled (just one of them: Python). Not to mention the fact that installing udev changed from a matter of "configure / make / make install" into a much more complicated job. Patches to allow udev to be built separately from systemd were rejected.
The blog post says that people are free not to use systemd because "free software isn't Mafia" ; well, the reader will decide what kind of behaviour it is to push people into using systemd by making their life noticeably harder if they don't.
Anyway, after we discovered that, unlike was promised, things would indeed change for non-systemd users of udev, we finally got an official announcement by the systemd lead developer stating that they dislike having to support non-systemd users, and that they look forward to the day when they'll get rid of the "inconvenience".
Now, it doesn't matter if his dreams of Linux domination will become true in 2013, in 2014 or in 2020. This statement is of extreme importance now, because:
(1) the use of udev is for all practical purposes required in order to fully make use of the Linux kernel;
(2) the udev maintainers are claiming that they are working to stop supporting udev without systemd in a somewhat unspecified future (and, as anyone can see, in the meantime they are already behaving as if non-systemd users of udev were second-class citizens, and are publicly stating it in order for it to be well known);
from (1) and (2) we get that non-systemd users are friendly advised to either stop using the Linux kernel, or prepare themselves to develop and maintain an alternative to udev. Or, much more conveniently, switch to systemd.
No you can't. Try to do it and tell me your experience.You can still build udev solo,
You still can, but it's a pain in the ass, which it wasn't before the udev-systemd merger, and most importantly, it's a use case with an expiration date. Which is unacceptable.you can still use it without systemd.
Please forgive me for this rant in a systemd thread, but hearing people say that non-systemd users of Linus exaggerate or are paranoid when they say that they're being pushed into using systemd, means having insult added to the injury to me.
The really heavy obstacles in our world are beliefs:
, this a long time Gentoo advocate at:RANT! Someone is trying to turn Linux into Windows! They're trying to turn it into "Just Works (TM)", ...
Therfore true Linux/Unix is: It has to just NOT work!
Otherwise it is a conspiracy ....
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.
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.
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.*
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.
Description: is what appears when someone looks at the daemon through systemctl (systemctl status adsuck)[Unit]
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"
ExecStopPost=/bin/sh -c "cp /var/adsuck/resolv.conf /etc/resolv.conf"
ExecReload=/bin/kill -HUP $MAINPID ; /bin/kill -USR1 $MAINPID
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
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 11:59 PM.