[05:35] if i wanted to port a sysvinit script to upstart, is there a page documenting how to do this? [08:37] hi [08:38] telexicon: does the script do the stantard start/stop/restart stuff? [08:39] yes [08:40] I am pretty new to this but what I do is write a very simple job "start on start-myservice , stop on stop-myservice" and put the exec in there [08:40] let me find a simple sample [08:41] it'd be nice if there were a few non-trivial examples on the wiki at least [08:41] for making scripts for daemons or something [08:43] http://paste-it.net/7198/raw/ [08:44] after that I "emit start-myservice" [08:45] but I agree that there is room for improvement in the docs and specialy examples [08:46] I would really like a non sysv example. [08:46] ah ok [08:46] well id like to see converting a standard sysv init script to an equivalent upstart form [08:47] telexicon: the thing really is that the guts of sysv are in the file called inittab , there are the read progams that get started and stopped at a special runlevel [08:47] the "rc" scripts are really implemented differently by every distro. [08:48] ok [08:48] but ubuntu has done away with inittab [08:49] telexicon: yes ,while ubuntu uses upstart it uses a "sysv" like implmentations that emulates the old system [08:50] if you have a ubuntu system running you can look in /etc/event.d/ and grep for inittab to see the "hacks" [08:52] I am implmenting a state machine based system atm(something like the runlevels but with more possible transitions between the levels) [08:53] in other words i am experimenting :PO [08:53] ah [08:54] I think that what I would like is to have more conventions something like /etc/upstart/services/[myservice] [08:55] and that by default I can call emit myservice-start [08:56] everything is a job in upstart therms. perhaps it is better to wait for somebody with more knowlegde [14:04] OK , I have my next interesting problem :p [14:05] I have an init script that starts two commands in the background and I want to convert that one to "one or tree" jobs [14:05] I really wonder how... [14:06] is that /etc/upstart/services/[myservice] [14:06] a good idea anyway? [14:07] or can a jobs have multiple exec's? [14:09] err [14:09] I'm not sure what you mean [14:09] can you be more verbose? === kylem_ is now known as kylem [14:50] I am trying to replace some old init scripts that performed start_a & start_b & (if stop killall a killall b) [14:51] I kinda like the idea that a service can consit of multiple processes (like the nfs/portmap hell) [14:52] \ [14:52] shouldn't they be multiple services? [14:53] what benefit would there be for having them as one [14:53] you need portmap for things other than nfs, for example, so it needs a separate lifecycle [14:54] perhaps , I like the idea of being able to star "something" and don't want to know that that something actualy consist of multiple parts [14:54] right [14:54] but that can be done with events, where each part starts something else? [14:54] e.g. "start dbus" causes all dbus services like NM to start [14:55] Yes , I think that that would be valid [14:57] how about the /etc/upstart/services/[myservice] idea [14:58] or actualy whould/should it be possible to have a "start script and a stop script? [14:58] it is possible [14:58] if you have /etc/event.d/foo [14:58] then you can do "start foo" and "stop foo" [14:59] "emit start foo" [15:01] initctl start foo [15:01] the latter, not the former [15:01] emit is for making events [15:01] start/stop are for starting and stopping jobs [15:02] events can, of course, start and stop jobs [15:02] but there's a more direct way [15:03] the symlink trics also works (BTW) so creating a symlink start to initctl [15:03] Keybuk: I am holding my breath [15:03] yes [15:04] make install will do that for you [15:10] hmm yes, I would love the split the even listener and the services, perhaps just giving them an extention is a good (and compatible) start [15:13] FYI this is a part of my "change_handler/state_machine" http://paste-it.net/b33db14/raw/ [15:43] err, what does that do? [15:43] -- [15:43] the way I'd do NFS/portmap would be to have an nfs-server service that starts the actual nfs server [15:43] and in portmap have [15:43] start on starting nfs-servre [15:43] so if you "start nfs-server" you get portmap [15:43] -- === soren is now known as soren_not_joking === soren_not_joking is now known as soren_joking === soren_joking is now known as soren [17:42] * Keybuk cannot figure out what the buggering bollocks a D-Bus VTable is [17:43] Must be somehow related to D-Bus flicking you the Vs. [17:47] it's a pointer which is typedef'd to a struct that appears to be internal to D-Bus [18:22] *sigh* [18:22] my test suite continues its long-standing tradition of finding bugs in other people's software [18:22] dbus has this function that tells you whether data is remaining to be dispatched [18:22] so assumedly you do: [18:23] while (dbus_connection_get_dispatch_status (conn) == DBUS_DISPATCH_DATA_REMAINS) [18:23] dbus_connection_dispatch (conn); [18:23] except it turns out that data_remains can be true if there are unparsed bytes in there too [18:24] so you'll be in a loop [18:24] and since dispatch doesn't read(), it'll loop forever [18:24] Heh [18:24] if you only call dispatch() once, it will only dispatch one message, and will sit at select() for the next incoming message [18:37] actually, I can shorten that still :) [18:37] while (dbus_connection_dispatch (conn) != DBUS_DISPATCH_DATA_REMAINS) [18:37] ; [18:40] that seems to cure the problem, in fact [18:40] Nice [18:53] Keybuk: the upstart code and nih looks very nice indeed. [18:54] what kind of tests are you talking about (I also saw a post/news about it) [18:56] look under the nih/tests and init/tests directories [18:56] or just run "make check" [18:58] thanks [20:01] Keybuk: so, what was your final answer wrt the license for the example jobs? [20:01] sadmac_: MIT/X11 [20:03] http://upstart.ubuntu.com/download/example-jobs/COPYING [20:04] cool [20:06] 203 if (! dbus_bus_register (conn, &error)) { [20:06] (gdb) n [20:06] 204 nih_dbus_error_raise (&error); [20:06] (gdb) p error.name [20:06] $2 = 0x2b367a0d0be8 "org.freedesktop.DBus.Error.NoMemory" [20:06] (gdb) p error.message [20:06] $3 = 0x2b367a0d5600 "Not enough memory" [20:06] weird [20:07] oh [20:07] just a silly error [20:07] it seems it always adds watches and timeouts to the main loop [20:07] even if you just want it to block [20:07] (multi-thread safe I guess) [20:13] Keybuk: using the dbus C api I see. [20:14] Keybuk: good. DBus cannot become an excuse for GObject. [20:14] indeed [20:14] *shudder* [20:14] GObject is wrong [20:14] and the dbus bindings to it are actually just as weong [20:15] quest nih% ./test_dbus [20:15] :1.183 [20:15] \m/ [20:15] I have achieved ... A CONNECTION! [20:15] Keybuk: my initial attemt at writing a little /etc/rc replacement was previously done by someone else with GObject. It was 1/3 the way to working and probably had more code than upstart. [20:15] :p [20:15] whee [20:16] last time I used GObject it made me want to kill every single glib developer [20:16] in fact, i often get that feeling just using glib [20:18] AlexExtreme: I often get that feeling just laying awake at night [20:18] haha [20:20] *** [20:20] *** #upstart is now known as #theglibfanclub [20:21] glib (adj): showing little forethought or preparation : offhand [20:22] "lacking depth and substance : superficial " [20:22] did you know that it's another word for castration? [20:22] I feel the same way about both [20:23] Keybuk: so you would rather become a woman than a GNOME developer? [20:24] one is certainly more likely than the other [20:24] I got told "I don't contribute enough" to be a GNOME developer [20:24] Women tell me that all the time. [20:26] I think my most hated thing about glib is the way that it implements libc functions itself and just sticks g_ in front, and typedefs g to for many types [20:27] AlexExtreme: its a performance thing. G is a very fast character, because its right next to your pointer finger. So it makes the front of variables quicker. [20:28] haha [20:28] the front is the part in 'high' memory, and glib people believe in doing many things while high [20:30] interesting [20:30] my iPhone kernel paniced [20:31] URL? [20:31] keybuk: Congrats. :-) [20:32] glib has gint and such for portability reasons [20:32] it future proofs the library for new architectures [20:32] *HOW* [20:32] how is gint any more portable than the int type its typedef'd to?!: :) [20:32] make sure int is always the same size [20:32] but it doesn't [20:33] gint is int [20:33] on a new arch they can change gint to typedef to something else [20:33] but they don't [20:33] but they could :) [20:33] and, the best thing is, C *already* has typedefs for this [20:33] int32_t [20:33] uint64_t [20:33] etc. [20:33] if you *care* about the size [20:33] aren't those C99? [20:33] yes, they're from a C standard that is almost 10 years old [20:33] that many compilers still don't get right [20:33] in fact, I think C99 was C96 before, so more than 10 years old [20:34] name one [20:34] name a compiler that doesn't get them right that you can actually compile GNOME on :p [20:34] i think think windows has int16 [20:34] MSVC++ is one of the better C99 compilers out there [20:34] it might have other typedefs, but it certainly supports the standard [20:34] but this is the stdlib [20:34] SUNWspro certainly supports them [20:34] gcc does [20:35] Keybuk: gcc doesn't fully support C99, by their own admission. I don't know the discrepancies though. Obviously small. [20:35] i'm pretty sure windows doesn't have all of them [20:35] saw a debian guy bitching about this a couple days ago [20:35] you certainly don't need to protect the size of "int" [20:35] gchar [20:35] (!!) [20:36] whoah! fat characters! [20:36] Most people I know that are big into C consider C99 to be a failed standard though. [20:36] wasn't the main point of C99 to make C and C++ mix better? [20:36] sadmac_: http://gcc.gnu.org/c99status.html [20:36] also, glib is rather old... [20:37] everything might support that stuff now but did it in 2001? [20:37] glib is just over-engineered [20:37] that too [20:37] Keybuk: cool. [20:37] it's a library written for writing programs in C for people who don't like writing programs in C [20:37] just use vala :) [20:37] everything C-like is hidden so you can pretend you're writing in G [20:37] when, in reality, you probably just wanted C++ in the first place [20:38] or compiled C# or Java [20:38] but C++ is evil [20:38] glib is evil ;) [20:38] * sadmac_ still needs to learn Objective C [20:38] slightly less evil :) [20:38] the difference between C++ and glib in terms of evil is like the difference between Steve Ballmer and Bill Gates [20:38] at least C++ *knows* its evil [20:38] Java is more evil than C++. C# is somewhere between the two. [20:38] C# is pretty nice, really [20:38] it wakes up in the morning, has a good manic laugh, and sets out to see what new evil it can bring to the day [20:39] :-) [20:39] glib just brings the same evil without trying [20:39] C# does generally seem nice [20:39] it was invented by the guy who did Delphi and ObjectPascal [20:39] and I liked them [20:39] it was? [20:39] I'd rather use C# than C++ because if I'm going to have to deal with that bullshit at least I don't have to deal with memory management and pointers :P [20:39] my only issue with it is that its interpreted [20:39] Digital Mars D looks nice, but the implementation just isn't there yet. [20:39] Keybuk: which vala 'fixes' :) [20:55] * sadmac_ looks into vala [20:55] interesting [21:17] yay [21:17] I *think* I have dbus now hooked properly into the nih main loop [21:19] Yay [21:29] of course, that's the easy bit [21:30] sending messages and handling those you get is the hard bit ;) [21:33] :-) [21:55] server = nih_dbus_server ("unix:abstract=/com/ubuntu/upstart/test"); [21:55] if (! server) { [21:55] err = nih_error_get (); [21:55] printf ("ERROR: %s\n", err->message); [21:55] exit (1); [21:55] } [21:55] ... [21:55] ahh, a nice API at least [21:56] Great [21:57] ok, that still needs to have something to handle publishing objects [21:57] etc. [21:57] but in theory, all upstart needs to call is nih_dbus_server() to handle direct clients and nih_dbus_system_bus() to handle indirect [22:28] nih_error_get sounds like a 4chan meme [22:28] 250 ERROR GET! === sadmac__ is now known as sadmac