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