From: "Lennart Sorensen" <lsore...@csclub.uwaterloo.ca> > Other than Ubuntu, who uses it? >
From: "Lennart Sorensen" <lsore...@csclub.uwaterloo.ca> > Does RHEL6 use it by default, or just include it as an option? What I > have found doesn't make it clear. From: Ingo Wichmann <iw-lis...@villa-vogelsang.de> > When I install RedHat 6, upstart is the default. > Actually, the question of Upstart in RHEL6 is answered by "getting into the details" of Upstart. ;) E.g., I'm running some free LPIC-1 training here in Orlando (FL USA) at my local LUG's monthly InstallFests and we did a comparison of Ubuntu LTS 10.04 Update 4 and Red Hat Enterprise Linux release 6 (EL6) Update 4, both originally released in 2010. The "key details" can be found by looking at the Upstart /etc/init (that's /etc/init, not /etc/init.d) directory. EL6 has less than 1/3rd of the files as Ubuntu LTS 10.04, meaning EL6 is far more reliant on backward compatible Sys V init. But at the same time, one still needs to understand Upstart for init, spawning, etc... in EL6. So I don't think covering Upstart is exactly "optional" in LPI objectives today and for the next 2-3 years at a minimum. As far as ... From: "Lennart Sorensen" <lsore...@csclub.uwaterloo.ca> > It was optional in some Suse versions, but they now use systemd. > It was used in some fedora versions, but they now use systemd. > It is an option in RHEL6, but isn't the default. > Debian considered it, but didn't end up using it. > I don't think Chrome OS counts, nor does WebOS or meemo. > Seems like there would be a better argument for systemd than upstart, > just based on the number of distributions using it. Remember, systemd and, to an extent, Upstart are *not* just "init replacements." They are "run-time system management" solutions. Now yes, systemd goes a bit further in that it has automatic dependency detection via D-Bus and Sockets, which Upstart does not. And one can consider systemd to be an universal monitoring solution for not just services, but resources and other dependencies beyond just services. I.e., in the very near future, most multi-system/network-wide audit, monitoring and other solutions will just start probing systemd instead of having all of their one-off solutions to do the same for various services. So ... what should LPI do? Well, LSB still factors in here. E.g., even though Upstart requires manual dependency listing in its service files, it does so fairly well to LSB init field standards. So those fields in Upstart are automatic for LSB init any way. The few directories that are Upstart-specific, like /etc/init, is also akin to systemd's /lib/systemd (packaged defaults) and /etc/systemd (system-specific or linked to packaged defaults) directories as well. So just cover those in tandem, for both solutions. E.g., where there is similar concepts to cover for both, do so and contrast. And as far as systemd being a plethora of solution replacements beyond just *.services, LPI could limit scope to just the *.services details for now. As systemd adoption kicks into high gear for things other than *.services, a LPI revision can address those based on actual, widespread adoption. I.e., many of us have long believed that real-time, pre-existing D-Bus/Socket-based monitoring/respawning -- things that are already built into modern Linux kernels/systems -- was only a matter of time, because Enterprise Linux users absolutely need it.** Lastly, _both_ have full backward compatibility with Sys V init, and LPI is already covering those too. Just my suggestions. I think both Upstart and systemd can be covered, under a limited scope, where they are beyond LSB init and legacy Sys V compatibility. As systemd's adoption goes well beyond *.services, LSB can adapt. I mean, neither Red Hat Enterprise Linux release 7 (EL7) nor SuSE Linux Enterprise Server release 12 (SLES12) are here with systemd yet, so I'd limit the scope to systemd's *.services where it contrasts with elementary Upstart for now. -- bjs DISCLAIMER: None of my statements are those of my employer, associates or anyone else but myself. **P.S. For years, customers have used monit as their init, or even ran Red Hat Cluster Suite Luci-Ricci on a single, standalone node (not actually clustered) just to monitor local resources and services. Static management and hard-coded service dependencies (let alone advanced resource monitoring) aren't what sysadmins have been asking for, let alone do now have on some select, other platforms too (e.g., Solaris). Systemd is just the first system that offers it for GNU/Linux, using existing kernel and userspace facilities (if systemd wasn't the solution, something else would do it and use the same mechanisms), and beyond, for servers more so than desktops. Yes, systemd is _not_ something for just desktops, quite the opposite, actually more for servers. Most people are unaware of this, because they never dove into the reasons why systemd (among the other "*d" solutions) was (were) developed when Upstart (and other approaches) already does (do) init "quite good enough."
_______________________________________________ lpi-examdev mailing list lpi-examdev@lpi.org http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
