| === zz_Cidan is now known as Cidan | ||
| [diablo] | Good morning #upstart ... guys how can I tell an upstart conf file not to fork please? I want the script thats getting called to fully run before upstart continues | 07:00 |
|---|---|---|
| [diablo] | or at least finish before the login prompt | 07:00 |
| [diablo] | would running the script as pre-start be better? | 07:04 |
| === Cidan is now known as zz_Cidan | ||
| === zz_Cidan is now known as Cidan | ||
| === Cidan is now known as zz_Cidan | ||
| afournier | hi i updated an home made system from 1.6.1 to 1.7 so upstart runs as PID 1 and assert after processing some events: "com.ubuntu.Upstart.c:2651: Assertion failed in control_emit_event_emitted: env != NULL" | 15:31 |
| afournier | any idea ? | 15:31 |
| afournier | i traced this problem up to this bug report, but here we are using it as init (PID 1)... https://bugs.launchpad.net/upstart/+bug/1161329 | 15:33 |
| jeffreylevesque | any fine wizards here? | 18:20 |
| jeffreylevesque | i created an upstart script, which works. Except, the datetime is always the same - https://github.com/jeff1evesque/machine-learning/blob/master/puppet/environment/development/modules/compiler/templates/webcompilers.erb#L38 | 18:20 |
| jeffreylevesque | how can i adjust the `echo` statement, so the datetime correctly reflects the current time for the `echo`? | 18:20 |
| jeffreylevesque | any bots in here with enough ai to answer my q | 18:30 |
| chras | jeffreylevesque: whats happening now ? that when you do a start you get the same time ? | 19:26 |
| jeffreylevesque | had to move it into the `exec` - https://github.com/jeff1evesque/machine-learning/blob/3277f30c1bf47f84c449370c7d1dffdc3bccb084/puppet/environment/development/modules/compiler/scripts/sass#L14 | 19:27 |
| jeffreylevesque | it's all fixed | 19:27 |
| chras | jeffreylevesque: yeah, thoes stanzas are their own independant sh's | 19:28 |
| chras | cant pass variables between them | 19:28 |
| [diablo] | evening guys | 21:18 |
| [diablo] | can anyone please tell me how the hell I tell an upstart conf file to run a script that sleeps for 60 seconds, but does not fork... I want the entire boot process to pause for the full 60 seconds before continuing | 21:18 |
| [diablo] | sadly I'm needing to do it in RHEL6 which is running upstart 0.6.5 | 21:19 |
| chras | so you want rest of bootup to depend on that one sleeping event, just to pause bootup ? | 21:44 |
| [diablo] | hi chras | 21:44 |
| [diablo] | well actually I'll explain | 21:44 |
| [diablo] | I have done for RHEL7 an expanding storage system with vmware guest ... | 21:44 |
| [diablo] | on boot, it must rescan busses, expand the lvm, and grow the fs | 21:45 |
| [diablo] | problem is with RHEL6, the extending of ext4 takes some time... I don't want the boot to continue and the user to login before it's finished | 21:45 |
| [diablo] | I thought that the process was getting killed by upstart for hanging around too long... because I saw sometimes it only grew the fs say by half... | 21:46 |
| [diablo] | so I need really two things... to be sure that the boot waits until the grow fs has completed, and that the process does not time out | 21:47 |
| chras | while its off topic, couldnt you do thoes things concurrently while people are logged in ? | 21:47 |
| [diablo] | hmmm | 21:48 |
| chras | thoes are all safe to do while online | 21:48 |
| [diablo] | yes | 21:48 |
| [diablo] | but | 21:48 |
| [diablo] | if a user is in a rush, hypothetically he could login, not see the fs has fully expanded and wonder why it's not the size he'd asked for | 21:49 |
| [diablo] | I'd much prefer the delay being on the boot until login, and the fs fully expanded by the time he's logging in | 21:49 |
| chras | well you could always make your getty/gdm/whatever depend on your resize event finishing succesfully | 21:50 |
| [diablo] | yes | 21:50 |
| [diablo] | thats true... | 21:50 |
| [diablo] | however I prefer not to edit those files... ideally I just want to drop in a /etc/init/resize.conf | 21:50 |
| [diablo] | and not mod anything else | 21:50 |
| chras | there shouldnt be any limitation to how long it takes for your upstart event to finish | 21:51 |
| [diablo] | chras, yeah actually I think the timeout was when I was trying out doing pre-script or something akin | 21:51 |
| chras | you could temporarily overwrite the start on for your getty.conf | 21:51 |
| chras | with getty.override | 21:51 |
| [diablo] | oh ok | 21:52 |
| [diablo] | one sec. let me find something | 21:52 |
| chras | i havnt done any long running pre-start's | 21:52 |
| [diablo] | guess it's minigetty on rhel | 21:52 |
| chras | but i quite often do running-forever stuff in script stanaza's | 21:53 |
| [diablo] | oh I've got a starttys | 21:53 |
| chras | yeah i dont know what the redhat upstart events are, or if you are using custom ones | 21:54 |
| [diablo] | chras, can't find much info really on upstart on rhel6, just the norm | 21:55 |
| chras | i use all custom events for our events | 21:55 |
| chras | never used any standard or base ones | 21:55 |
| [diablo] | I'll look into this override | 21:56 |
| chras | that might be simpliest way to do waht you want | 21:56 |
| chras | i think you need 1.3+ for it | 21:56 |
| [diablo] | doh | 21:57 |
| [diablo] | no, it supports it 0.6.5 | 21:57 |
| [diablo] | just found it in the man | 21:57 |
| [diablo] | so I'd put something like start on resize | 21:58 |
| chras | start on stopping resize | 21:59 |
| chras | best bet | 21:59 |
| chras | since you want it to trigger after your resize event is finished | 21:59 |
| [diablo] | ah gotcha | 21:59 |
| [diablo] | giving it a whirl now | 21:59 |
| chras | and then you could even flag that based on succes/fail | 22:00 |
| chras | but i assume in the end, you want the user to be able to log in regardless | 22:00 |
| [diablo] | hmmm sadly not working, most likely my mistake... | 22:02 |
| [diablo] | but you've given me food for thought | 22:02 |
| [diablo] | many thanks chras | 22:02 |
| chras | what didnt work ? | 22:03 |
| chras | didnt get your getty? | 22:03 |
| [diablo] | did't wait for login prompt | 22:03 |
| chras | so your resize ran , and then your login prompt fired | 22:04 |
| chras | without resize finishing | 22:04 |
| [diablo] | ah I see I did something wrong | 22:04 |
| [diablo] | one sec | 22:04 |
| [diablo] | hahaha chras I think you've nailed it... I'm running a sleep 60 cos I'm testing it out at home on a vm | 22:06 |
| [diablo] | splash has gone, no login yet... | 22:06 |
| [diablo] | chras, dude u da man | 22:07 |
| [diablo] | works! | 22:07 |
| chras | nice one | 22:07 |
| [diablo] | thats exactly what I wanted ! | 22:07 |
| chras | you might have to check a fail case with that, just in case a resize never happens | 22:07 |
| [diablo] | chras, aye | 22:07 |
| [diablo] | dude many thanks really | 22:08 |
| chras | are you doing your resize in a script, or a pre-start script? | 22:08 |
| [diablo] | it's been pissing me off all afternoon... | 22:08 |
| [diablo] | now it's gone midnight here ... gonna have to head to bed | 22:08 |
| chras | i dont recall if a stopping event will fire if a pre-start fails | 22:08 |
| [diablo] | cheers dude and all the best! god bless IRC :) | 22:08 |
| chras | have a good one | 22:08 |
| mjnowak | Anyone have a minute to possibly help me out with a nginx not respawning problem? | 23:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!