| Alpha1650 | Hi. I have a little question about upstart: As I understood, "console output" means that this task uses the console for input and output. What happens if two tasks need console for in- and output? Does the second have to wait until the first ended? Or can they run both simultaneously? Then what happens if both want to read something from console the same time? | 01:19 |
|---|---|---|
| === h\h is now known as haraldh | ||
| === Md_ is now known as Md | ||
| Alpha1650 | Hi. I have a little question about upstart: As I understood, "console output" means that this task uses the console for input and output. What happens if two tasks need console for in- and output? Does the second have to wait until the first ended? Or can they run both simultaneously? Then what happens if both want to read something from console the same time? | 10:52 |
| Keybuk | Alpha1650: they interleave and steal characters from each other | 10:54 |
| Keybuk | depends who's first to call read() | 10:54 |
| Alpha1650 | Keybuk: Okay, that doesn't sound very good. I'm having this ubuntu issue here with mountall and cryptsetup interleaving and breaking the splash and making it a gamble whether the machine will boot or not. I just set mountall's console to "none" what seems to make the machine bootable with splash disabled. | 11:00 |
| Keybuk | Alpha1650: on lucid? | 11:00 |
| Alpha1650 | Keybuk: Karmic. | 11:00 |
| Keybuk | ah, yeah | 11:00 |
| Alpha1650 | Keybuk: Are there any ideas/chances/intentions to solve the interleaving issues with upstart or is this what the apps will have to solve themselves? | 11:00 |
| Keybuk | I don't think it's up to Upstart to arbitrate the console | 11:02 |
| Keybuk | there are already better ways to do that | 11:02 |
| Keybuk | e.g. Plymouth | 11:02 |
| Alpha1650 | Keybuk: Do you know what mountall needs the console input for? As far as I can see it's first duty is to mount the filesystems when their devices come up. What does it need console (especially input, output might be for fsck or so) for? | 11:07 |
| coolo | Alpha1650: fsck also needs input on errors | 11:09 |
| Keybuk | right, fsck error recovery, etc. | 11:17 |
| Alpha1650 | Keybuk: coolo: I see, but then this is really an uggly situation where some kind of syncronisation and queuing of console-input/output-events is necessary, no? Maybe something like "interaction_start()" and "interaction_stop()" where scripts can within do input and output that belongs together, for example the password prompt and the following input in cryptsetup. And other tasks reaching a interaction_start() have to wait until the o | 11:19 |
| Keybuk | actually it's more than that | 11:20 |
| Keybuk | multiple cryptsetup devices might need to ask for the passphrase at the same time | 11:20 |
| Keybuk | you need something for everything during boot to talk to that deals with the screen | 11:21 |
| Keybuk | which might be a plain text console or a graphical console | 11:21 |
| Keybuk | as I said, Plymouth solves this already | 11:21 |
| Alpha1650 | Is there a project site for Plymouth? | 11:23 |
| Alpha1650 | I don't understand how Plymouth could solve the multiple tasks interleaving problem without syncronising at least their input | 11:24 |
| ion | Kind of. Its API doesn’t seem to allow multiple clients to query things at once, with the user being able to switch focus between them. The API also doesn’t seem to provide asynchronous queries, so that you ask a question, get an answer handle, go do other stuff and get a message over a file descriptor with the handle and the user reply (which should be handled by the plymouth client library by calling a callback you provided when asking the question). | 11:24 |
| Keybuk | ion: huh? it's API allows exactly this | 11:25 |
| ion | The latter issue already causes a problem with Upstart: there’s a user that consistently has his startup hang because Upstart just happens to say “didn’t find the device for a mount, what to do?” and blocks on the answer, although the device does appear very soon. | 11:25 |
| ion | keybuk: Ok, i’ve misinterpreted it then. I didn’t take a good enough look at the plybootclient/whatever headers. | 11:26 |
| ion | It didn’t seem to provide a way to integrate with an arbitrary main loop, instead it just seemed to provide a way to jump to its main loop until something happens, which isn’t good if you want asynchronous queries. | 11:28 |
| Keybuk | plymouth's main loop uses epoll | 11:28 |
| Keybuk | which is infinitely stackable | 11:28 |
| Keybuk | the mountall integration is a bit poor because I wrote it in a hurry | 11:29 |
| Keybuk | needed it in before Alpha/Feature Freeze | 11:29 |
| Keybuk | can fix it later as "bug fixing" :p | 11:29 |
| ion | Yes, it wouldn’t be hard to make plymouth provide an API to do that. Just one function to provide plymouth’s epoll fd and another function to call from your main loop when there’s something on that fd. Perhaps it already does, i might have missed it when skimming through the API. | 11:30 |
| Alpha1650 | Keybuk: you wrote on your blog that plymouth will not be used because it relies on kernel mode setting. | 11:30 |
| ion | alpha1650: Many months ago, in the context of another Ubuntu release? | 11:31 |
| Alpha1650 | Months ago, yes. Sep 2009. | 11:31 |
| ion | Things change. :-) | 11:31 |
| Alpha1650 | Yea, so this already changed. Good. (I have nvidia hardware that will not work with kernel mode setting I think.) | 11:32 |
| Keybuk | Alpha1650: that's not what I wrote | 11:33 |
| Alpha1650 | Keybuk: Then I misunderstood you. What did you write? | 11:33 |
| Alpha1650 | Keybuk: Yea, I got causality wrong. | 11:35 |
| Keybuk | Alpha1650: we didn't use plymouth in karmic because we already had usplash | 11:35 |
| Keybuk | which could already do KMS (it turned out)( | 11:35 |
| Keybuk | and there was a strong push to keep with usplash unless there was a truly compelling reason to switch | 11:35 |
| Keybuk | especially since plymouth wouldn't support non-KMS hardware | 11:36 |
| Keybuk | fortunately it turned out there were some bugs in usplash that needed fixing | 11:36 |
| Keybuk | and one of the key people who was pushing for keeping usplash got involved in fixing them | 11:36 |
| Keybuk | and remembered how nasty and ugly the code was | 11:36 |
| Alpha1650 | Keybuk: :D | 11:36 |
| Keybuk | so I was able to push plymouth again for lucid with the key feature "it means you don't have to fix usplash again" :p | 11:37 |
| ion | :-) | 11:37 |
| Keybuk | for lucid, plymouth was accepted with no resistance | 11:37 |
| Alpha1650 | Okay, so my hope can return, that Ubuntu will succeed this time in what it failed for the last 3 years: Making splash and dm-crypto work together properly. | 11:38 |
| Alpha1650 | I really had no ubuntu install where dm-crypto and splash worked smooth. Always problems. | 11:39 |
| Keybuk | the release manager himself is caring a lot about cryptsetup | 11:39 |
| Keybuk | and working actively on it | 11:39 |
| Alpha1650 | :) | 11:41 |
| Alpha1650 | So this issue will hopefully be fixed in the future. What about now? How can I make mountall work together properly with my crypto? | 11:41 |
| Keybuk | it will be fixed in lucid | 11:45 |
| Alpha1650 | Yea, but Lucid will be released in months. Shall I not turn my PC off and on again in that time? ;) | 11:45 |
| Keybuk | there's no plan for an update to karmic | 11:47 |
| Keybuk | or, if you prefer, the update is lucid ;) | 11:47 |
| Alpha1650 | Keybuk: Well, but until then a workaround for those people like me out there would be nice. You know the issue and know what's happening there. What would happen, if I set the "start on" of mountall from "startup" to the event when my /home-crypt-device was decrypted for example? cryptsetup does in no way depend on what mountall does, right? So why not let mountall depend on what cryptsetup does? | 11:52 |
| Alpha1650 | This would maybe delay the mount for a short period of time but I'm sure everyone having this issue is willing to pay this "price" for the solution. | 11:52 |
| Keybuk | there isn't a workaround | 11:53 |
| Keybuk | like you say, it's broken | 11:53 |
| Keybuk | a lot of work has gone into karmic to fix it | 11:54 |
| Keybuk | new packages | 11:54 |
| Keybuk | new integration | 11:54 |
| Keybuk | etc. | 11:54 |
| Keybuk | none of this is trivial to backport to a stable release | 11:54 |
| Keybuk | err, into lucid | 11:54 |
| Alpha1650 | Yea, sure. I do fully understand that there is no reasonable way to fix this by a package update. But to me (correct me if I got something wrong!) this seems to be a syncronisation issue, right? So my hope is that you can find a workaround that will make you loose some of your parallel execution brought by upstart but will ensure that those commands run in the right order and don't interfere. | 11:57 |
| Keybuk | we're not looking for a workaround for karmic at this point | 11:58 |
| Keybuk | karmic was released in October | 11:58 |
| Keybuk | the whole point of a six-monthly release schedule is that you're always working on the *new* release | 11:58 |
| Keybuk | once a release is out of the door, it doesn't tend to get updates | 11:59 |
| Keybuk | the update is the next release | 11:59 |
| Alpha1650 | So if it doesn't work, it doesn't work and people should stop using their computer, go outside, enjoy sun (or snow in this case), return in 6 month and try again? | 12:00 |
| Keybuk | updates sometimes break a minority of users | 12:01 |
| Keybuk | it's a fact of life | 12:01 |
| Keybuk | this is one of the reasons we recommend backing up a computer before upgrading to a new release | 12:02 |
| Keybuk | just in case the new release has a critical regression for you | 12:02 |
| Keybuk | obviously we will do everything we can to fix the regression | 12:02 |
| Keybuk | and, especially if it affects a large number of users, or is security-related, even do an update to the release | 12:02 |
| Keybuk | but we can't always do that | 12:03 |
| Keybuk | sometimes the fix is so large or fundamental that it has to be "sorry, we'll have that fixed in the next release" | 12:03 |
| Alpha1650 | Yea, I have my old install around here, so the backup exists. But I like karmic, so ... | 12:03 |
| Keybuk | that's another reason we have the LTS releases | 12:04 |
| Keybuk | they're a slower, more stable cycle for the kinds of users who can't risk a little downtime | 12:04 |
| Keybuk | or a little manual hacking | 12:04 |
| Keybuk | and we *do* do big stable updates for them | 12:04 |
| Alpha1650 | Well, as I said, I see that fixing this cleanly would be a lot of work. | 12:04 |
| Keybuk | e.g. we've not long released 8.04.4 - another update to hardy | 12:04 |
| Alpha1650 | But I'm disappointed that there is absolutely no "hacking workaround" for this issue. That's what I don't understand. | 12:05 |
| Keybuk | Alpha1650: I don't know cryptsetup well enough | 12:05 |
| Alpha1650 | No package update or so, just a "howto live with this bug if you have it". | 12:06 |
| Keybuk | I've heard of people hacking their crypttab so that all of the passphrases are asked for in the initramfs | 12:06 |
| Alpha1650 | Keybuk: Yea, exactly such things! | 12:06 |
| Keybuk | but such things tend to be different for every person | 12:06 |
| Alpha1650 | Already thought about this but couldn't find the options yet. | 12:06 |
| Keybuk | it could take a developer a month to research the issue and write a howto | 12:06 |
| Keybuk | that's a third of the development time of lucid! | 12:06 |
| Alpha1650 | :P | 12:06 |
| Keybuk | it could even mean the bug never gets fixed for lucid | 12:06 |
| Keybuk | because the only developer who knows enough spent their entire time worrying about the bug in karmic | 12:07 |
| Keybuk | now, often in the process of fixing a workaround is made obvious | 12:07 |
| Keybuk | but in this case, the bug is "we got this completely wrong" and the fix is "redo it all from scratch" | 12:07 |
| Keybuk | thus there's no real obvious workaround | 12:07 |
| Alpha1650 | No, the crypttab-thing you talked about is the kind of workaround I was looking for. | 12:08 |
| Alpha1650 | Dirty but useful. | 12:08 |
| Keybuk | so try that | 12:08 |
| Keybuk | the bug reports are probably a useful source of ideasa | 12:08 |
| Alpha1650 | is initctl emit the way to emit signals within upstart tasks? | 12:13 |
| Alpha1650 | Or are there other ways? | 12:13 |
| Keybuk | initctl emit is the way to emit events | 12:14 |
| Alpha1650 | Okay, thank you. | 12:14 |
| Alpha1650 | Keybuk: Is mountall the one who shuts down the splash to do fsck? | 12:15 |
| Keybuk | Alpha1650: mountall logs to the splash | 12:15 |
| Keybuk | not sure why the splash would vanish | 12:15 |
| Alpha1650 | Keybuk: Hm, okay. Something is stopping splash and then the fsck output appears ... | 12:17 |
| acemo | where should i place a new upstart script(i want it to be executed at start up)? | 13:39 |
| Keybuk | acemo: /etc/init | 13:43 |
| Alpha1650 | Keybuk: I found "my own little workaround" for the ubuntu mountall-cryptsetup issue: - disable splash screen (as this breaking and reenabling it during boot is quite annoying) - I copied the "cryptroot"-script from initramfs, named it "crypthome" and modified it in a way that it runs directly before cryptroot in initramfs and decrypts the /home. This makes booting a fast and reliable thing again. :) | 13:48 |
| Alpha1650 | Thank you all for your help in answering my questions, especially Keybuk. | 13:48 |
| acemo | I have this script http://pastebin.com/m23288b88 at /etc/init/spawn-fcgi-php but it seems to be not getting started. What am i doing wrong? | 13:54 |
| plautrba | acemo: only 1 "start on" stanza is accepted and you have to rename your job file to have ".conf" suffix | 14:00 |
| acemo | plautrba: thanks, that did the trick =) | 14:02 |
| acemo | would using exec sudo -u username echo 'bla' be the right way to let upstart run a program as a different user? | 14:09 |
| plautrba | Keybuk: upstart-0.6.5.tar.bz2 is missing. It is intended? | 15:01 |
| plautrba | *Is it | 15:01 |
| Keybuk | yes | 15:03 |
| plautrba | ok | 15:04 |
| Keybuk | with libnih out, there's no real difference between the sizes | 15:04 |
| Keybuk | and the .tar.gz is more widely accepted | 15:04 |
| plautrba | just for sure | 15:05 |
| sadmac2 | plautrba: why did you update to 0.6.5? the cvsbot hasn't even created a libnih repo yet. | 15:34 |
| plautrba | sadmac2: it's prepared in devel branch | 15:34 |
| plautrba | f13 was branched out yesterday | 15:34 |
| sadmac2 | plautrba: we still can't build it anywhere | 15:35 |
| plautrba | sadmac2: it's not tagged yet | 15:36 |
| sadmac2 | plautrba: meh. fair enough :) I think we'll want it for F13 too. Its a minor enough update that we can put it in. | 15:37 |
| plautrba | sadmac2: sure, f13 is goal, but you can check it in devel branch now | 15:37 |
| plautrba | sadmac2: i've figured out that libnih.spec really needs %define _filter_GLIBC_PRIVATE 1 | 15:40 |
| plautrba | but libtool-2.2.6a-rpath.patch is not necessary | 15:40 |
| sadmac2 | plautrba: I didn't pull either out since the package was reviewed. Figured I'd do it as I checked them in. | 15:41 |
| sadmac2 | plautrba: something about the move from /usr/lib{,64} to /lib{,64} must've made the libtool thing go away. | 15:41 |
| plautrba | sadmac2: it's done with first sed in %build | 15:42 |
| sadmac2 | plautrba: ah yes. | 15:42 |
| === Md_ is now known as Md | ||
| acemo | is using sudo and exec the correct way to run a service as a different user as root? | 21:18 |
| notting | runuser should work | 21:18 |
| acemo | okay lets see if this works ^.^ | 21:26 |
| acemo | hmm nope | 21:27 |
| acemo | the part between script and end script.. can i put a normal shell script in there? like this.. http://pastebin.com/m39f4ca91 or is it a whole different sort of script? | 21:33 |
| sadmac2 | acemo: yep, its just pumped through /bin/sh | 21:34 |
| acemo | aweasome! | 21:34 |
| sadmac2 | acemo: I would use daemonize=false though, so you don't need to mess with expect stanzas | 21:34 |
| sadmac2 | acemo: and I'd exec it | 21:35 |
| sadmac2 | acemo: and move the chmod to post-start | 21:35 |
| acemo | ohh great, ubuntu doesn't has runuser | 21:39 |
| acemo | http://pastebin.com/m4ab0da0 im so far now, i'll just have to find out how to get runuser on my ubuntu machine and am not sure about the post-stop part.. it has to be chmodded before someone gets to be able to see the site. | 21:51 |
| notting | huh. it's part of our coreutils package | 21:58 |
| notting | (our == fedora) | 21:58 |
| acemo | notting: runuser seems to be a stripped down version of su | 22:00 |
| mxey | is runuser a tool supposed to be used to switch to another user before starting a daemon? | 22:04 |
| mxey | Or what is the way to achieve that? | 22:05 |
| acemo | mxey: not sure.. am trying to mess around with it now | 22:10 |
| mxey | I think there should be an option for this, like there are options for chdir, chroot and umask. | 22:10 |
| mxey | btw, I really like the oom option. | 22:10 |
| acemo | oom option? | 22:11 |
| mxey | setting the OOM killer "priority". Helpful for setting critical services like SSH to oom never. | 22:12 |
| acemo | i c | 22:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!