Does `juju-log` Needs the `JUJU_CONTEXT_ID` Environment Var?

juju
,
#1

Resolved: :white_check_mark:

I’m pretty sure about this, but I wanted to get extra verification. In order for juju-log to work it needs a JUJU_CONTEXT_ID right?

Lucky charms have a daemon that stays running for the time that the charm is installed. I have the daemon using juju-log for its logging, but it seems that the logs stop coming through to the juju debug-log after the first install hook runs. I realized that this is probably because the daemon continues to have the same JUJU_CONTEXT_ID that it recieved from the install hook when other hooks are run.

I doubt it, but is there anyway to have something log to the Juju log outside of a charm context so that the logs will come through regardless of whether a charm hook is currently running? I suppose I could use juju run 'juju-log "mesage"' maybe. Would using juju run for every log message be inefficient because it has to create a new context every time?

If I have to, I can make sure to update the logging context every time a charm hook is run, but then if anything happens in the Lucky daemon while a charm hook isn’t running, the user would not see those logs, which would be confusing and ineffective.

Normally, nothing happens in a charm without a charm hook running, but feature I have considered adding to Lucky was the ability to run “cron” scripts or other asynchronous scripts which would result in scripts being run outside of the Juju hooks.

Edit:

I just realized, maybe I can create a Juju context specifically for the Lucky daemon by doing juju run 'lucky daemon start --foreground'. Then that context should exist until the daemon process exits.

#2

OK, so I’m running into some trouble creating a context to run the daemon in. The lucky daemon needs to be started on the install hook. I tried to do a juju-run inside of the install hook so that I could run the daemon in its own context, but juju-run won’t do anything into the install hook finishes, so it gets into a deadlock and never finishes installing.

In order to get around the “You can’t use juju-run inside of a hook” I did something this:

CONTEXT=$JUJU_CONTEXT_ID
unset JUJU_CONTEXT_ID
juju-run $JUJU_UNIT_NAME './bin/lucky daemon start'
export JUJU_CONTEXT_ID=$CONTEXT

But, as I stated above, it gets into a deadlock because juju-run will never exit

I’m not sure if there is a way around this. :thinking:

Edit: At this point I’m thinking that the daemon will need to piggy-back on the contexts from the initial setup hooks where juju-run will not work and then wait until the first update-status hook before it can use juju-run to get its own context that can exist outside of the hooks. It isn’t a perfect solution and I’ll see if I can think of anything else, but I’m kind of coming outside of Juju’s typical operating model and there might need to be extra feature in Juju to facilitate what I’m wanting to do properly, if this is even something that we want Juju to allow charms to do.

#3

I’m finally understanding that there can be only one Juju context for a given charm at any given time. Doing a juju-run will lock that charm from running any other hooks until it exits ( think ) and as long as a charm hook is running you cannot execute a juju-run until it finishes ( which I have tested and verified as far as I can tell ).

I think that this will be mostly OK for Lucky, it just means that the daemon will have to have its own log that will not be visible through juju debug-log. In practice, because the daemon will be able to use juju-log whenever it runs a charm script and obtains a Juju context, most, if not all, of the logs that will be useful to the user will end up in the juju debug-log. I believe this will be satisfactory.

The one context situation does mean that you cannot have asynchronous scripts, but that is probably for the best anyway and it does not remove the option to have scripts executed on a cron schedule by the daemon, it just means that while a cron script is running no other Juju hooks can be running, and vice versa.

Resolved: :white_check_mark:

1 Like
#4

Thanks for the stream of work there. Just to provide some context.

Yes, there’s only one hook at a time that can run. This helps prevent cases where an install hook is running and a config-change event comes along but the config isn’t even going because install is still running.

juju run will let you execute a shell command and it’ll have what we call “hook context” so you’ll get access to the Juju environment variables and setup as if your run was executing from within a hook, but it’s a little bit different than you were expecting it looks like.

What the reactive and I think other charm setups do is leverage the fact that the storage-attach hook is run before anything else (so that if your install needs to place something in that storage location you’re good to go) and uses that as an entry point to setup the charm so that everything will be available and running when it wants. I could see that that hook would install and setup a systemd service for your own daemon in a standard fashion if that’s something you’re looking to possibly investigate.

1 Like
#5

Cool, I’ll move my daemon setup to storage-attach then. Thanks.