| === rangerpbzzzz is now known as rangerpb | ||
| rharper | smoser: http://paste.ubuntu.com/23124387/ -- looking at the event reporter output; with the context manager, we get a start/finish for each manager; however, for the stage runners, we don't seem to get the 'start' event; in the paste, notice we have an extra finish, which is the other half of the 'start' of the module .. any idea why we don't get that first start event ? | 15:36 |
|---|---|---|
| smoser | how did you give it the config you wanted ? | 15:38 |
| smoser | rharper, ^ ? | 15:40 |
| smoser | i think maybe it didn't know of the config until after it started/ | 15:40 |
| rharper | this is defaults | 15:41 |
| rharper | I'm parsing cloud-init.log output to recreate the records | 15:41 |
| rharper | if you look at cloudinit/cmds/main.py, it's the args.reporter which sets up the event stack with the name. | 15:41 |
| rharper | it does seem like the first event isn't "published" to the logger; so maybe it's just getting chewed somewhere in that util.log_time | 15:52 |
| smoser | rharper, try turning of rsyslog | 16:33 |
| smoser | in /etc/cloud/cloud.cfg.d/05_logging.cfg | 16:33 |
| smoser | comment out - [ *log_base, *log_syslog ] | 16:34 |
| rharper | ok | 16:35 |
| rharper | I'll give that a shot | 16:35 |
| === rangerpb is now known as rangerpbzzzz | ||
| rharper | smoser: that didn't help; but I'll dig in and see what's up in main.py w.r.t the __enter__ | 17:34 |
| rharper | 2016-09-02 17:48:13,667 - util.py[DEBUG]: Cloud-init v. 0.7.7 running 'init-local' at Fri, 02 Sep 2016 17:48:13 +0000. Up 1.0 seconds. | 17:51 |
| rharper | 2016-09-02 17:48:13,669 - util.py[DEBUG]: Writing to /var/log/cloud-init.log - ab: [420] 0 bytes | 17:51 |
| rharper | smoser: I think that clobbers the log file right after we've published the start event | 17:51 |
| rharper | so we miss the start event for each stage invocation, if that's true | 17:52 |
| rharper | let me remove that and see what it looks like | 17:52 |
| smoser | well, it does say 'ab' | 17:59 |
| smoser | but i guess quitei possibly athe first message was not flushed, and the filehandle probably still open | 17:59 |
| rharper | yeah; still chasing it; it's just getting lost in logger; | 18:05 |
| rharper | I can see it getting published via the LogHandler and it's configured | 18:05 |
| rharper | we don't have this issue with curtin, so something is different | 18:05 |
| rharper | smoser: I don't understand how it can be fixed, but basically, since we don't "reconfigure reporting" until after the Init stage is created (and we call apply_reporting_config() with the initial cloud config ) then we lose the first set of reporting events (logging gets them but they're not ever emitted to /var/log/cloud-init.log) | 19:30 |
| rharper | it isn't terrible since not a log happens, but in terms of having matched pairs of events (start/finish); there's no point to starting the reporting event stack until after Init.stage2 is complete | 19:31 |
| smoser | rharper, yeah. i gues reconfigure_reporting could re-send the current one. | 19:34 |
| rharper | smoser: I don't know how we'd be able to replay previous events; | 19:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!