| TJ__ | if i have the init script called rc.conf that handles the system-V compatibility, i should be able to have some script start when this is finished by having start on stopped rc right ? | 08:51 |
|---|---|---|
| jhunt | TJ__: if by script you mean job configuration file (/etc/init/*.conf), yes. | 08:53 |
| TJ__ | ok... strange, all jobs that have that start line, dont seem to start | 08:53 |
| TJ__ | have to dig little deeper then | 08:54 |
| TJ__ | jhunt, can this event stopped rc be forced ? | 09:20 |
| jhunt | TJ__: you can do that, but why would you want to? | 09:24 |
| TJ__ | to test if the job is started | 09:24 |
| jhunt | TJ__: status <job> | 09:24 |
| TJ__ | its stopped, while other jobs with same "start on condition" have been started | 09:26 |
| jhunt | TJ__: http://upstart.ubuntu.com/cookbook/#init-checkconf | 09:27 |
| TJ__ | aaaaah | 09:30 |
| TJ__ | damn | 09:30 |
| TJ__ | found it | 09:30 |
| TJ__ | thanks | 09:30 |
| jhunt | TJ__: np. | 09:30 |
| TJ__ | what process is in charge of starting jobs based on scripts in the etc/init dir ? | 14:17 |
| TJ__ | and what if that process starts after the start-on condition is met in any of these scripts ? | 14:18 |
| jhunt | /sbin/init aka "upstart". I would highly recommend you read the upstart cookbook, and "man 8 init" and "man 5 init". | 14:18 |
| TJ__ | oki. thanks. | 14:21 |
| vaxerdec | does the version number of "example jobs" match the feature set of upstart at the time it also had that version number? | 15:07 |
| jhunt | vaxerdec: what example jobs are you referring to? | 15:09 |
| vaxerdec | and same question for libnih | 15:09 |
| vaxerdec | the ones on the download site | 15:09 |
| vaxerdec | the tarballs | 15:09 |
| jhunt | ? | 15:10 |
| vaxerdec | http://upstart.ubuntu.com/download/ | 15:10 |
| vaxerdec | latest there is 0.3 for example-jobs. does this mean that they do not use any features added after 0.3 release? | 15:11 |
| jhunt | vaxerdec: I don't know, but quite possibly. as you can see, they haven't been updated in a while. | 15:12 |
| jhunt | vaxerdec: If you're wanting to write a new .conf file, I'd look at the cookbook, the man pages and a recent Ubuntu system for lots of good examples. | 15:13 |
| vaxerdec | yes. i've tried hunting for stuff, i am going to do a wholesale conversion of all my init scripts. i am successfully running fedora 15 with their shipped version of upstart (1.2) | 15:13 |
| vaxerdec | i am long-time redhat user. however i upgraded my system from 14 to 15 and it was only then that i discovered the horrible abombination called systemd | 15:14 |
| vaxerdec | abomination | 15:14 |
| vaxerdec | that is not unix software. | 15:14 |
| jhunt | :) | 15:15 |
| vaxerdec | i read countless mailing list archives to familiarize myself. that guy lennart is a total jerk frankly. | 15:15 |
| vaxerdec | he is incredibly arrogant and fills his arguments with logical fallacies, then tries to accuse others of doing it | 15:15 |
| vaxerdec | i can't believe redhat did that... i'm shocked. upstart is much more sensible | 15:15 |
| vaxerdec | this systemd junk appears to want to replace my entire unix operating system with a single C binary that does everything. | 15:16 |
| vaxerdec | i took a look at some of your dev branches | 15:17 |
| jhunt | Yes, Upstart actively tries to avoid that model. | 15:17 |
| vaxerdec | then why are you stuffing crond into it? | 15:17 |
| jhunt | we haven't stuffed crond in Upstart. | 15:17 |
| vaxerdec | there's a perfectly good cron daemon that exists already. it's called crond. or cronie, or anacron, or what have you. | 15:18 |
| vaxerdec | looks like in your devel branches as well as some notes. refers to replacing cron | 15:18 |
| jhunt | Keybuk wanted to implement an Upstart bridge to provide a cron-like facility. That feature doesn't currently exist although. | 15:19 |
| vaxerdec | next it will be /bin/ls and i have to use dbus to talk to upstart to run a directory listing. please don't :) upstart is good (except for apparnt dbus dependency). don't make mistake lennart does with systemd. | 15:19 |
| vaxerdec | trying to subsume all the standard system things into one daemon | 15:20 |
| jhunt | you misunderstand - upstart uses "bridges" for such additional functionality. These are out-of-process daemons that extend Upstart - they are not part of the core. | 15:21 |
| vaxerdec | over dbus? | 15:21 |
| vaxerdec | what happened to plain unix sockets or even ip? | 15:22 |
| vaxerdec | i'm not running dbus on my system now, and i hope i won't be prevented from upgrading upstart because of apparent dependencies on dbus | 15:23 |
| vaxerdec | do you know if i'll have to? | 15:29 |
| vaxerdec | have a dbus transport layer running, that is. in order to be able to even use later versions of upstart | 15:30 |
| jhunt | Upstart doesn't require a dbus-daemon process to be running - it has its own dbus server internally. However, it does use unix sockets too for performance. | 15:30 |
| vaxerdec | i don't mind having to build in a dbus library... well, i do, but it's a compromise as long as i don't have to use it and run a separate bus service. | 15:31 |
| vaxerdec | although it would be nice if the dbus could could be turned off completely... like ifdef'd out | 15:31 |
| vaxerdec | dbus code rather | 15:31 |
| vaxerdec | ahhh, that's a relief | 15:32 |
| vaxerdec | i noticed in changelog you had started to say that it is "now required" and it had been "added as a dependency" | 15:32 |
| vaxerdec | which made me nervous. i'd have to start calling a shell script as /sbin/init and do it all myself! (will kernel even run an interpreter for pid 1? hmm) | 15:33 |
| vaxerdec | well, as in, a standalone scripot with a hash-bang line... | 15:34 |
| vaxerdec | i've got to figure out a way to stop this guy lennart. this man is insane | 15:35 |
| vaxerdec | he wants to put everything and anything in his precious systemd. | 15:36 |
| vaxerdec | also this totally specious argument about fast boot... i mean it's silly. are people continuously rebooting their computers or something? really how important is that to shave off microseconds from the boot time? | 15:39 |
| vaxerdec | sure, parallelizing things and doing async socket IO is great. can we be done now? it's fast enough already. if upstart gets close to that speed (which it probably is already, with properly written stanza files), then it's plenty fine. | 15:40 |
| jhunt | Upstart was designed from the outset for performance and reliability. | 15:41 |
| vaxerdec | i think it is fine peice of software. i have been playing with it so much today i totally shirked my other duties. | 15:43 |
| vaxerdec | i noticed you guys have implemented the virtual services now? to form dummies for tacking onto? sort of like groups? | 15:44 |
| jhunt | glad you're enjoying it. | 15:45 |
| vaxerdec | i do think the model of event based that you started with rather than dependency based, is probably harder to debug and inherently less deterministic. however it seems that you're basically implementing service dependencies now with the virtual services everyone can pin to. if i understand them right | 15:47 |
| vaxerdec | i really hope redhat's push for this systemd junk can be stymied somehow. they even *had* upstart and then switched!!! grrrr | 15:49 |
| jhunt | vaxerdec: RHEL 6 uses Upstart. Fedora uses systemd. | 15:50 |
| vaxerdec | yes i was going to say that | 15:50 |
| vaxerdec | it leads me to believe systemd will just be a failed experiment like so many others in fedora | 15:50 |
| vaxerdec | the thing with upstart though is that you really have to *think* to get the scripts right sometimes. and play around with it... unlike systemV, which a child could understand. | 15:52 |
| jhunt | maybe, but sysV has serious limitations which Upstart overcomes. | 15:53 |
| vaxerdec | also after switching and getting rid of ConsoleKit, it looks like nobody is setting permissions on the tty anymore, at least /dev/console | 15:54 |
| vaxerdec | it looks like it used to be done in a pam limits file but that doesn't sound very good to me. is it ok to chown right in the upstart script? | 15:54 |
| jhunt | if you want to. However, udev should be doing that sort of thing for you. | 15:55 |
| vaxerdec | hmm, that's quite a beast. | 15:55 |
| vaxerdec | wait, it can only activate on device-change events though really, right? i mean that's when it normally is woken up | 15:56 |
| vaxerdec | you'd still have to have upstart call some kind of udev trigger, i don't think someone logging out of the console and another one sitting down is anything that layer is aware of | 15:57 |
| vaxerdec | udev is yet another peice this lennart fellow is talking about putting into his daemon. | 16:00 |
| vaxerdec | reading rawhide changelogs, maintainer after maintainer is actually ripping *out* a perfectly working, maintained by upstream sysv init script (which could at least by an upstart system during rc.conf). so i have to go off and find them somewhere, or write my own. but that's good because almost none of their scripts were upstart-native anyways | 16:08 |
| vaxerdec | s/by/be used/ | 16:08 |
| vaxerdec | and then a /run ? i mean just for your special software? an entry in the root of the filesystem? come on dude. | 16:11 |
| vaxerdec | ok, i'll stop complaining now, sorry. | 16:11 |
| vaxerdec | i just can't believe it. the crap these guys are now trying to shove down my throat. anyone using unix for just a few months would understand that all-in-one tools are anathema to the unix philosophy. | 16:12 |
| vaxerdec | i just was so glad there was a good alternative in upstart. i wanted to thank you guys for keeping your eye on the ball and putting out some really good work. | 16:12 |
| vaxerdec | one problem i see though getting this adopted is lack of standard names conditions for special events that form sequencing barriers... i mean all the events that come out of the scripts themselves voluntarily, from 'emit' | 16:15 |
| jhunt | have you seen "man upstart-events" on ubuntu? | 16:15 |
| vaxerdec | i now about that, but it's ubuntu (and is not in the RH version for some unknown reason i can't fathom) | 16:16 |
| vaxerdec | i sample a few upstart scripts from different distros and nobody has standardized | 16:16 |
| jhunt | it is somewhat distro specific, but some standardisation would be a good thing I agree. It's on my list. | 16:17 |
| vaxerdec | i think relying on special names may not be a great idea for that... if there was some way to rely on like "capabilities" of the init script that would be easier perhaps. but then, i guess you'd have the same problem with capability names. and not sure how you could programmatically determine some of these from upstart itself... maybe special names are the best/only way in fact | 16:19 |
| vaxerdec | it would be really nice if vendors could all agree on the virtual-provides and -requires, the generic names... but i doubt it. probably just stuck shipping different versions for each distro. or sourcing a central file each distro has one of... like a 'services' map. | 16:20 |
| vaxerdec | then again, we do have the LSB... and there are other examples of vendor cooperations | 16:21 |
| vaxerdec | if you think about it, maybe it's not really distro-specific at a certain level of abstraction. every server is doing basically the same thing with basically the same software. even different unix platforms still are all roughly the same at that level | 16:23 |
| vaxerdec | i guess the desktops would vary considerably though, hm. | 16:23 |
| vaxerdec | you know dennis ritchie died | 16:24 |
| vaxerdec | hm seems like we will soon have chrome on gtk/wayland running on KMS. | 16:32 |
| vaxerdec | maybe finally i will have no more reason to use X (the graphical web browser). | 16:32 |
| vaxerdec | anyways, ok i guess i am disproportionately talkative and mostly just blowing hot air | 16:32 |
| vaxerdec | maybe i will switch to ubuntu. screw these guys and their kiddie servers! | 16:34 |
| vaxerdec | just so familiar with redhat ways... | 16:35 |
| vaxerdec | i don't know if i could | 16:36 |
| vaxerdec | i really can't stand the way-too-long name 'start-stop-daemon' | 16:37 |
| vaxerdec | then again, /etc/sysconfig/network-services is way too long. | 16:37 |
| vaxerdec | do you actually keep upstart-services(7) up to date anyways? | 16:40 |
| vaxerdec | i haven't looked at your code yet either... I will check out trunk. | 16:42 |
| vaxerdec | oh fascinating. that "go" language from Google, was designed by Thompson and Pike | 16:43 |
| vaxerdec | is trunk considered stable? | 17:04 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!