Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
What about RedHat 6?
In a strange twist, Redhat will need to support upstart for several years now.
Shuttleworth: Quality has a new name
Posted Apr 26, 2012 0:27 UTC (Thu) by dlang (✭ supporter ✭, #313)
this may impact the 'obvious' move to systemd in RHEL7, it depends on how disruptive this is to sysadmins and if RedHat is willing to change init packages twice in two releases.
I think that people assume that if something is in Fedora, it will be in the next RHEL. Even if Fedora is the testing ground for RHEL (something disputed by Fedora people regularly), there's still time for the test to fail (for some definition of fail)
Posted Apr 26, 2012 1:11 UTC (Thu) by jspaleta (subscriber, #50639)
Upstart was introduced in Fedora (just as it was in Ubuntu) running in a sysVinit compatibility mode...which created upstart native jobs that mimicked traditional runlevels to run everything else.
In Fedora i'm pretty sure none of the installable services...such as sshd ever had upstart "native" job files and were run as traditional initscripts under the compatibility mode. I expect RHEL 6 to be using upstart in the same way. Which is to say...as close to a replacement of sysvinit and no further than that.
And since I asked the question originally I've looked over the open upstart bugs that have bubbled up in the context of other discussions and it seems upstart has some long standing issues that prevent conversion of a number of significant services like apache and other forking services.
Bug from 2010:
This is pretty much a showstopper for "native" upstart process control across an important swath of daemon (especially for the cloud..cough cough.) I am NOT saying this is unfixable. The original lead developer clearly thought it was fixable...in 2010..by moving away from ptrace in how upstart did its magic. But its NOT FIXED going on a year and a half later to my understanding.
This really brings home the point I think that Canonical has a problem keeping up with their own project development long term. Canonical's choice to keep upstart would make more sense if they were actively cultivating upstart so it could be a full init replacement so all services could gain access to the enhanced event based job control. But they aren't. They made a push to "go native" for as much as was feasible..but they haven't fixed upstart to be able to take it further and complete the work. That's a problem. The longevity of that bug speaks to focus and to quality more than perhaps a lot of people inside the Canonical fenceline realize.
An init replacement system that can't be used to transition from the legacy sysvinit scripts to get access to advanced job flow control features sort of defeats the point a little bit. Especially for a company that is really pushing the server motto. But hey if they want to stick their heels in the sand they are only hurting their own long term prospects. It's always a bit sad to watch it happen. Hopefully they'll double down and put some more engineering manpower into getting upstart polished off instead of letting it linger a slow death.
Posted Apr 26, 2012 11:16 UTC (Thu) by ovitters (subscriber, #27950)
Posted Apr 28, 2012 23:23 UTC (Sat) by speedster1 (subscriber, #8143)
Posted Apr 28, 2012 23:42 UTC (Sat) by Cyberax (✭ supporter ✭, #52523)
Though RHEL7 should be fairly soon - in 2014 or so :)
Posted May 1, 2012 17:05 UTC (Tue) by BenHutchings (subscriber, #37955)
They don't even update kernels between releases.
Yes they do. And it's not just updating drivers; they've backported quite large new features, like KVM into RHEL 5.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds