Aka/Joel: Any idea how to implement this?

I think adding the following to dbus/org.chromium.hammerd.conf should be enough:

<allow send_destination="com.ubuntu.Upstart"
       send_interface="com.ubuntu.Upstart0_6.Job"
       send_type="method_call" send_member="Start"
       send_path="/com/ubuntu/Upstart/jobs/hammerd"/>

I think #4 is fine. Otherwise we need to write the information at the file when hammerd is invoked, and remove the file by udev rule when the base is detached.

Toni: Can you implement your suggested change? Thanks.

I didn't realize that hammerd is a short-running service rather than a persistent daemon. (The name may be partially responsible for my confusion... :-P) Is the plan to stick to that model going forward?

hammerd is currently started in response to the hammer-device-added Upstart signal, right? Can you just configure the job to run when the ui job restarts instead of making Chrome explicitly ask for it to run over D-Bus? I'd prefer to avoid using multiple systems to manage the a single job's lifecycle.

Yeah, I was initially  mislead by the name, too.

I'll defer to drinkcat and akahuang to answer the questions about hammerd service, but I'm slightly concerned that running the job on ui restart might be slightly racy - would this necessarily happen after Chrome has set up dbus signal listeners (i.e. can we assume Chrome would notice signal send by hammerd if the job is started on ui restart)? 

> can we assume Chrome would notice signal send by hammerd
> if the job is started on ui restart

Probably not, unfortunately. We emit login-prompt-visible when the login screen is shown, but if you also need to handle other Chrome restarts I don't know if there's anything similar yet.

The usual way we handle cases where Chrome needs state at startup is by making Chrome query for the initial state over D-Bus (see https://chromium.googlesource.com/chromiumos/docs/+/master/dbus_in_chrome.md#Sharing-state-between-processes), but that's not going to work if hammerd is a short-lived process.

What was the reason for making hammerd non-persistent, by the way? http://doc/17zkQAzTfVi5kdvyUs-VmgbkMZ5ht0sLzya5kEa1Qu8I doesn't seem to go into detail about this (and even mentions in one place that maybe it should be a daemon).

If keeping hammerd non-persistent is the only option, I'd suggest adding a new Upstart signal ("chrome-started", "chrome-dbus-ready", or something similar) that can also be used to trigger the hammerd job. Chrome could make a D-Bus call to session_manager asking it to instruct Upstart to emit the signal. We already use this mechanism for other Upstart signals:

- EmitLoginPromptVisible emits "login-prompt-visible"
- EmitArcBooted emits "arc-booted"

Thoughts?

I think, making hammerd persistent, and expose methods for getting the detachable base state would likely be the preferred solution to handle this problem. That said, I'm not familiar with reasons it's a short-lived process, and how feasible/desirable would it be to change that.
drinkcat@, akahuang@, should have more context about this.

Emitting chrome-started signal would likely work, but I'm not sure whether extra work to add this signal would be justified by having all triggers for hammer service listed at the same place (unless the signal might be useful in other circumstances). Though, my opinion on this is probably not the most relevant one :)

Also, hammerd process by itself doesn't really have a good reason to run on Chrome start (the main reason it's run is that Chrome needs information from it) - i.e. I think it would be harder to understand why hammerd is run on Chrome start than why Chrome requests hammerd to run.

+drinkcat@, who seems to have fallen off the cc list

iiuc, hammerd is only for updating the firmware on the device, so once that (uncommon) event has passed, there's no reason to keep hammerd resident.  so making it always persistent doesn't sound like a win to me, just a waste of resources.

I went with the flow proposed by derat in comment #9, so closing this as WontFix (the implementation is being tracked in  issue 818057 )