Bugzilla – Bug 2406
Need support for upstart services
Last modified: 2012-02-10 17:33:25 UTC
Neither Pacemaker nor the LRM currently have support for upstart services. Suggest to introduce a new class "upstart" in analogy to "lsb", which ties in with upstart to start, stop, and monitor services.
This becomes a problem immediately on Ubuntu 10, where at least Samba is unusable now via the regular init script (it's not even installed). I'm assuming other services suffer similarly. Is there any sense in keeping the LSB resource class, but having LRM transparently use upstart (invoke "service foo ..." or whatever it is) to manage those resources on upstart-systems?
Bumping severity to major. Per tserong's comment, this is already affecting distributions.
Yes, seems to be urgent, though I hope that most clusters rely on OCF. Florian: You have some Ubuntu box to try stuff out? According to the documentation, the interface is like this: # start service # stop service # status service Is there more to it? How to find out if we're running on a distribution which uses upstart? How to get the list of installed services? How to produce the metadata, as we do that now for the LSB class? I'll be away until Tuesday. If somebody want's to give this a try, it should be easy starting from a copy of lib/plugins/lrm/raexeclsb.c
(In reply to comment #3) > Yes, seems to be urgent, though I hope that most clusters rely on OCF. Florian: > You have some Ubuntu box to try stuff out? I certainly do; might be a few days until I can actually test something though. Or do you want me to just test upstart stuff on a non-cluster? That's easily done. > According to the documentation, the > interface is like this: > > # start service > # stop service > # status service > > Is there more to it? Yes, there is also restart and reload (don't know if this is relevant to lrmd in any way, though). > > How to find out if we're running on a distribution which uses upstart? That's beside the point. Most distros who use upstart to day have mixed startup jobs, some upstart, some LSB/SysV. SHould be up to the admin to decide whether they want to use LSB or upstart. > How to get the list of installed services? Maybe as simple as "ls /etc/init/*.conf" ? > How to produce the metadata, as we do that now for the LSB class? Fetch description from the .conf file, perhaps? What other metadata do you need?
(In reply to comment #3) > How to find out if we're running on a distribution which uses upstart? # /sbin/init --version 2>&1 | grep -q upstart \ && echo "upstart" || echo "old school" Might be a bit rough :)
(In reply to comment #4) > (In reply to comment #3) > > How to find out if we're running on a distribution which uses upstart? > > That's beside the point. Most distros who use upstart to day have mixed startup > jobs, some upstart, some LSB/SysV. SHould be up to the admin to decide whether > they want to use LSB or upstart. We'd need that to figure out whether to look for the agents and show the class to the users. For instance in the crm shell. > > How to get the list of installed services? > > Maybe as simple as "ls /etc/init/*.conf" ? That sounds good enough for me. Similar is done for the LSB. > > How to produce the metadata, as we do that now for the LSB class? > > Fetch description from the .conf file, perhaps? What other metadata do you > need? Whatever is required. There's a description at the top of init scripts, we need something which can be parsed and transformed. Don't know what does .conf file look like.
(In reply to comment #5) > (In reply to comment #3) > > How to find out if we're running on a distribution which uses upstart? > > # /sbin/init --version 2>&1 | grep -q upstart \ > && echo "upstart" || echo "old school" > > Might be a bit rough :) Looks ok to me. Perhaps just to test -d /etc/init?
Other methods to start/stop/status with upstart is using initctl: initctl start <service> initctl stop <service> initctl status <service> There is also a DBusInterface: http://upstart.ubuntu.com/wiki/DBusInterface
Any news here? Andres, did you start implementing this class?
(In reply to comment #9) > Any news here? Andres, did you start implementing this class? Hi Dejan, I've just got back from the Ubuntu Developer Summit yesterday so I've not started implementing it, however I've been looking at the code to get familiarized with it, and will start this week. Now, I think we are gonna run into problems due to Upstart does not yet provide exit codes. Any suggestions on how to proceed? This issue was discussed at the UDS and it was asked to the Upstream Developer of Upstart to implement the exit codes ASAP. Cheers,
Patches for upstart support in cluster-glue can be found at: http://www.init.hr/dev/cluster/patches/
(In reply to comment #11) > Patches for upstart support in cluster-glue can be found at: > > http://www.init.hr/dev/cluster/patches/ I wonder how you ever got those to compile without http://hg.linux-ha.org/glue/rev/e284cd6f4786 :) Anyway, for anyone trying out these patches: please make sure your local cluster-glue checkout is current up to at least revision e284cd6f4786.
Created attachment 1705 [details] Patch to make upstart support conditional Upstart/D-BUS may not be available on some old platforms we build on, and it's not necessary to build Upstart/D-BUS support on distros that don't manage services with upstart. Thus, make upstart support a conditional that depends on the --enable-upstart configure option, and keep it disabled by default.
Created attachment 1706 [details] Properly check for dbus-binding-tool during configure Add a proper autoconf check for dbus-binding-tool.
Dejan, OK if I push these patches upstream? They don't interfere with existing functionality at all, and add a feature that is disabled by default. Having them in upstream hg would make it easier for people to test this.
Florian, I've renamed PKG_ into XPKG_, but didn't include it in patches. Sorry. I've added 2446.diff and 2447.diff that solve two issues you've raised (on IRC). 2446 fixes starting/stoping already started/stoped service. And with 2447 it actually waits for service to finish starting.
(In reply to comment #15) > Dejan, OK if I push these patches upstream? They don't interfere with existing > functionality at all, and add a feature that is disabled by default. Having > them in upstream hg would make it easier for people to test this. Yes, please push them. Didn't have time to take a look yet and it may still take some.
(In reply to comment #17) > Yes, please push them. Didn't have time to take a look yet and it may still > take some. OK, I pushed all except http://www.init.hr/dev/cluster/patches/2444.diff which I'm not 100% sure about -- can you review that and see whether it is safe to go upstream?
(In reply to comment #18) > (In reply to comment #17) > > Yes, please push them. Didn't have time to take a look yet and it may still > > take some. > > OK, I pushed all except > http://www.init.hr/dev/cluster/patches/2444.diff which I'm not 100% sure about > -- can you review that and see whether it is safe to go upstream? Something like this should be better: CHECK_ALLOCATED(client, "client", ); if (client->g_src != NULL) { G_main_del_IPC_Channel(client->g_src); client->g_src = NULL; } if (client->g_src_cbk != NULL) { G_main_del_IPC_Channel(client->g_src_cbk); client->g_src_cbk = NULL; } lrmd_client_destroy(client); It looks like the upstart patches are Ubuntu-specific. If so, should it be named differently? Or is it that upstart runs only on Ubuntu? If not, is there a way to discover at runtime all the stuff such as these: +#define UPSTART_BUS_ADDRESS "unix:abstract=/com/ubuntu/upstart" +#define UPSTART_SERVICE_NAME "com.ubuntu.Upstart" +#define UPSTART_MANAGER_PATH "/com/ubuntu/Upstart" +#define UPSTART_IFACE "com.ubuntu.Upstart0_6" I'm worried that one day say Debian people come and ask for Debian upstart support.
> It looks like the upstart patches are Ubuntu-specific. They shouldn't be. Regarding dbus naming scheme, that's how it's done. Every project defines it's own name/path. For example, Pidgin has 'im.pigdin'. Usually, it's the reverse URL of the project's web page. http://pidgin.im -> im.pidgin | /im/pidgin/ http://upstart.ubuntu.com -> com.ubuntu.upstart | /com/ubuntu/upstart http://telepathy.freedesktop.org -> org.freedesktop.telepathy | /org/freedesktop/telepathy
Hi all, Any updates on providing support for upstart and the issue of having IPC sockets open and accumulating?? see [1] [1]: http://lists.linux-ha.org/pipermail/linux-ha-dev/2010-November/017791.html
This has finally been fixed in glib2 for Ubuntu. See: https://mail.gnome.org/archives/commits-list/2010-November/msg01816.html Closing.
*** Bug 2626 has been marked as a duplicate of this bug. ***
(In reply to comment #22) > Closing. Thanks. Indeed, it was a bug in Glib. This issue is fixed in Ubuntu 11.04 and newer versions. For 10.04, PPA is required: https://launchpad.net/~ubuntu-ha-maintainers/+archive/ppa/
On Fri, Feb 10, 2012 at 05:20:11PM +0000, bugzilla-daemon@developerbugs.linuxfoundation.org wrote: > https://developerbugs.linuxfoundation.org/show_bug.cgi?id=2406 > > --- Comment #24 from Ante Karamatic <ivoks@ubuntu.com> 2012-02-10 17:20:11 UTC --- > (In reply to comment #22) > > > Closing. > > Thanks. Indeed, it was a bug in Glib. This issue is fixed in Ubuntu 11.04 and > newer versions. For 10.04, PPA is required: > > https://launchpad.net/~ubuntu-ha-maintainers/+archive/ppa/ Thanks for the extra information. > -- > Configure bugmail: https://developerbugs.linuxfoundation.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the assignee for the bug.