I think the signal should be converted to an int in the API layer so that a StatusBadRequest can be returned for things like this as int is the final type for this var.

+1
Then we can remove daemon.ContainerKill

I thought about that, but I wasn't sure if we wanted callers to ContainerKill be able to pass in both ints and the string version w/o forcing everyone to convert it themselves.

I think we should enforce type. That was whole idea of removing jobs.

What will be if sig == ""?
Can we move whole ContainerKill here to work with container instance?

If sig == "" then the normal container.Kill() will be done.

I thought about removing ContainerKill() but then each potential caller would need to do the logging themselves and I didn't like the idea of that.

Ok, just looks weird comparing to other merged PRs. pause/unpause in particular. Also I think there won't be other callers.

This might be a bigger discussion (bordering on bikeshedding :-) ) but to me the api/server code is all about the http transport and I expect we'll eventually have others, so when that day comes I would want logic that isn't specific to the transport to be done within the daemon itself. And I consider logging of a container being killed to be the job of the deamon (or the container itself) but not the api/http/transport layer. So, in that respect I would prefer if we didn't remove those other daemon funcs, if nothing else to have consistency and proper separation of concern.

I'm not sure that I want introduce new event in this PR.

oh, is there a formal process to get events approved? I assumed this was an old comment and would be easy to fix. I'll revert it.

actually, can I just reuse the same event from above?

I think it should be sort of separate PR.
I don't know how to post signal to events - it is sorta break events format.