| shyam_k | i was wondering how to boot into two different user configurations from the same root partition from grub itself! is it possible? | 06:34 |
|---|---|---|
| sadmac_home | shyam_k: you could have different grub lines pass different kernel arguments. Then early userspace/init can read those arguments out of /proc/cmdline and boot the system differently | 06:40 |
| shyam_k | oh wow /proc/cmdline was new to me.. great:) | 06:41 |
| rohdef | why wont this: http://pastebin.com/d2d3c83e6 start automatically when the xbmc-live job is started? I placed it in /etc/init as I should (as far as I can read at least) | 13:27 |
| * rohdef is wondering if there's any activity here | 13:39 | |
| JanC | did you check if the xbmc-live job was actually started? | 14:00 |
| === robbiew_ is now known as robbiew | ||
| rohdef | JanC, I can see that it starts, since it's my complete gui, I'll try a reboot and check the status, but I'm very certain | 14:50 |
| rohdef | JanC, "status xbmc-live" returns "xbmc-live start/running, process 750" | 14:54 |
| rohdef | why wont this: http://pastebin.com/d2d3c83e6 start automatically when the xbmc-live job is started? I placed it in /etc/init as I should (as far as I can read at least), I also tried with other setups such as "start on startup" and "start on started hal". The script works fine when using "start krnet" | 16:08 |
| sadmac | rohdef: did start on startup and start on hal work? | 16:09 |
| rohdef | nopes | 16:09 |
| sadmac | startup should definitely work | 16:10 |
| sadmac | hmm | 16:10 |
| rohdef | I gotta admit I'm a bit puzzled about this myself, first time trying though, but it seems very straight forward, which makes it wierder to me that it doesn't work | 16:12 |
| rohdef | and it would be really typical if it's due to some very stupid detail :p | 16:12 |
| sadmac | rohdef: anything in /var/log/messages? | 16:12 |
| rohdef | sadmac I'll check just a sec | 16:13 |
| rohdef | sadmac, ... a segfault that could be caused by my script, only way I can see it possible is if it runs too early, I'll just try some things | 16:17 |
| rohdef | sadmac thanks a lot, your question lead me to the problem; premature execution | 16:27 |
| rohdef | gotta get used to the thought of asyncronious execution (actually a really good thing, just have to get used to it ;) ) | 16:28 |
| sadmac | rohdef: heh. glad to help. | 16:29 |
| superm1 | Daviey and I were talking the other day and were wondering how doable a feature for upstart would be to add a dependency that only exists if it's installed. for us it would be only starting before mysql if it's there, otherwise wait for the standard other things this same thing came up during UDS to try to solve a problem in the proprietary x session | 17:09 |
| Keybuk | I think it makes sense | 17:13 |
| Keybuk | you'd need the logic to automatically disable a job if other things weren't there | 17:14 |
| Keybuk | otherwise Upstart might think mysql exists if it was removed but not purged because /etc/init/mysql.conf still exists | 17:14 |
| Daviey | Keybuk: would it be possible to make upstart "apt aware"? | 17:27 |
| Daviey | ie, query the apt db? | 17:27 |
| Daviey | well i know it *would* be possible, but is it feasible? | 17:27 |
| Keybuk | you could do that | 17:28 |
| Keybuk | if you had an addon that parsed the apt db and created states for each installed package | 17:28 |
| Daviey | I imagine it would be quite expensive in time to do it for every upstart task.. but perhaps cache or add an apt hook? | 17:28 |
| Keybuk | and then you'd need it updated each time you changed the db | 17:28 |
| Keybuk | (you mean the dpkg db btw) | 17:28 |
| Daviey | yeah | 17:29 |
| Daviey | i'm trying to think of a way that is generic, rather than having specific code tied to an application/package | 17:37 |
| Daviey | actually, "if upstart job mysql exists" | 17:38 |
| Daviey | Does that make sense? | 17:38 |
| Daviey | I'm happy to try and help, but a few pointers would be appreciated :) | 17:39 |
| Keybuk | that's what I was thinking | 17:42 |
| Keybuk | have a state for "job exists" | 17:42 |
| Keybuk | while mysql or not exists mysql | 17:42 |
| Keybuk | type thing | 17:42 |
| Daviey | jah | 17:44 |
| Keybuk | though that's somewhat booleanly mad | 17:45 |
| Daviey | hmm | 17:50 |
| Daviey | syntatically? | 17:50 |
| Daviey | syntactically* | 17:51 |
| Keybuk | yeah | 18:33 |
| Keybuk | while foo or foo doesn't exist | 18:33 |
| Keybuk | because while foo if foo exists is a bit more difficult to parse ;) | 18:33 |
| sadmac | Keybuk: I've been thinking about an enable stanza | 18:33 |
| sadmac | Keybuk: that would allow you to shift other jobs into auto mode when it came up. | 18:34 |
| sadmac | Keybuk: basically its a way to do the "profiles" thing as jobs. | 18:35 |
| Keybuk | how do you mean? | 18:35 |
| sadmac | Keybuk: It works exactly like the before stanza, only its OR'd on the other end. for example, if you have 2 jobs with "before a" in them, then BOTH need to be running for a to start. If you have 2 jobs with "enable a" in them, then a can start as long as either one is running | 18:36 |
| Keybuk | still not following? | 18:36 |
| sadmac | Keybuk: ok, lets start with the practical case. So you had that idea to let the user list services they wanted to start at boot on the kernel command line right? | 18:37 |
| Keybuk | right | 18:38 |
| Keybuk | well | 18:38 |
| Keybuk | more to create pretend services | 18:38 |
| Keybuk | but yes | 18:38 |
| sadmac | Keybuk: basically, we'd have the kernel command line always name one service called "default" | 18:38 |
| sadmac | Keybuk: and the default service definition would just have stanzas like "enable hal / enable tty / enable X / enable dbus / enable ..." | 18:39 |
| Keybuk | I'd rather do that the other way around | 18:39 |
| Keybuk | in the HAL definition, have "while default" | 18:39 |
| sadmac | Keybuk: that makes it hard to create new profiles. | 18:39 |
| Keybuk | I don't think profiles are common enough to worry about it | 18:40 |
| sadmac | Keybuk: so if I wanted to create a new set of services called "turbo_mode" that had some different configuration, I'd have to edit every job I wanted to start in that mode. | 18:40 |
| Keybuk | sure | 18:40 |
| Keybuk | jobs start by default anyway | 18:40 |
| Keybuk | what you really want is a profile that disables jobs you don't want | 18:40 |
| sadmac | Keybuk: usually if you care enough to have profiles you have a huge number of services to worry about, and the set you want actually /running/ at any one time is much smaller than that. | 18:41 |
| Keybuk | right, so you're talking about someone who'd have upstart set up that all jobs were in manual mode by default | 18:42 |
| Keybuk | and explicitly enable the ones they wanted? | 18:42 |
| sadmac | Keybuk: sort of. basically all jobs would be in manual mode always unless hit by an "enable" stanza. | 18:43 |
| sadmac | Keybuk: the security people are going to murder you if you're not careful about this "default to running" thing :) | 18:43 |
| Keybuk | err | 18:44 |
| Keybuk | Ubuntu and Debian have always done "default to running" :-) | 18:45 |
| Keybuk | if you didn't want it running, why did you install the package? | 18:45 |
| ion | Indeed | 18:45 |
| sadmac | Keybuk: you didn't. A partial exploit allowed an attacker to get some privileges on the box. He was then able to install a service and get even more privileges because the service was turned on for him. | 18:46 |
| Keybuk | well | 18:47 |
| Keybuk | I guess Fedora defaults to letting anyone install any package | 18:47 |
| Keybuk | :D | 18:47 |
| sadmac | Keybuk: you're connecting exploits that get you one operation on one component and giving them the effectiveness of any exploit anywhere in the universe. | 18:47 |
| sadmac | Keybuk: we did for a bit actually... did you follow that? People were unhappy. | 18:48 |
| Keybuk | but going back to non-trolling for a second | 18:48 |
| Keybuk | I guess we're going to have to support the RH not-enabled-by-default mode | 18:48 |
| Keybuk | even if in Ubuntu we still enable-by-default | 18:48 |
| Keybuk | in that circumstance, I guess your proposal makes a crazy sense | 18:48 |
| Keybuk | though you'd have to manually update that job file each time a package is installed? | 18:48 |
| Keybuk | (to start it?) | 18:49 |
| sadmac | it also means profiles and services are one object. | 18:49 |
| sadmac | Keybuk: not necessarily... let me think about that | 18:49 |
| sadmac | Keybuk: part of the advantage here is "profiles are services" so we get all the same crazy tools to wire them together. | 18:49 |
| Keybuk | right that bit makes sense | 18:50 |
| sadmac | Keybuk: we still allow jobs in folders, right? You could enable by path. | 18:50 |
| sadmac | Keybuk: enable defaults/* | 18:50 |
| sadmac | ah, hello chkconfig. I remember you. Good to see you again. Have you been well? | 18:51 |
| sadmac | its not exactly chkconfig though, because you shouldn't need symlinks | 18:51 |
| Keybuk | yeah that kind of thing | 18:52 |
| sadmac | Keybuk: the other issue is you can't do a "disable" stanza because then you get a race between the service and the profile that turns it off. | 18:54 |
| Keybuk | indeed | 18:55 |
| Keybuk | enable makes sense though | 18:55 |
| Keybuk | there'd be a companion option (/etc/init.conf returns? :p) to actually enable the enable stanza | 18:55 |
| Keybuk | ie. if you were in enable-by-default mode, enable would do nothing | 18:55 |
| Keybuk | it only applies in disable-by-default mode | 18:55 |
| sadmac | Keybuk: Ooh, idea: you could have a "disable" stanza that just complements the enable stanza. So if /in the same job/ you had "enable foo* / disable food" you would enable anything starting with foo except the service called "food" | 18:56 |
| sadmac | Keybuk: then, we ship as I described, and you guys just ship a profile with "enable *". the user can then add disables to the bottom of that profile for explicit disabling. | 18:57 |
| Keybuk | or we could support zsh globbing | 18:57 |
| Keybuk | foo*~food | 18:57 |
| sadmac | Keybuk: I'd rather do glibc regexen | 18:57 |
| sadmac | Keybuk: at any rate zsh globbing would be less convenient for the use case I mentioned | 18:58 |
| sadmac | Keybuk: this way is actually really nice, because you can do either. Your single-user profile can have "enable this-one-thing", and your multi user profile can have "enable * / disable just-this-one" | 19:01 |
| sadmac | I don't think there's any other system who's effect can't be achieved this way, and its cheap to do. It seems right. | 19:02 |
| JanC | having a standard way to enable & disable services would also be useful for those who want to create a web or graphical UI to enable/disable services... | 19:03 |
| sadmac | and this way ends up being pluggable too, so tools won't step on each other's toes. | 19:03 |
| === robbiew is now known as robbiew-afk | ||
| === notting__ is now known as notting | ||
| === robbiew-afk is now known as robbiew | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!