[systemd-devel] We are working on Secure Container Applications.
lennart at poettering.net
Mon Jan 9 18:38:14 PST 2012
On Mon, 09.01.12 16:42, Daniel J Walsh (dwalsh at redhat.com) wrote:
> The idea is to run multiple instances of the same application within a
> container. For example multiple Apache servers.
> I am working on a tool to create these containers, which will create a
> service unit file.
> # virt-sandbox-service create -e /usr/sbin/httpd httpd_sanbox
> Created container dir /var/lib/libvirt/filesystems/httpd_sanbox
> Created sandbox config /etc/libvirt-sandbox/httpd_sanbox.sandbox
> Created unit file /etc/systemd/system/httpd_sanbox.service
> One problem we see with this is when the httpd program gets updated,
> it runs a systemctl reload httpd.service, to cause the httpd service
> to restart. We would like to get this reload command from systemd
> What do you guys think of adding something like the following to the
> service unit?
> ReloadRequest: httpd.service
> Then anyone asking to reload the httpd.service would also cause the
> httpd_sandbox.service to get the reload.
Hmm, yupp I think this would make sense, after all we already are
capable of propagating restart requests between services, along
requirement dependency paths. So we probably should provide the same for
reloading, too (though this needs to be independent of requirement
deps). So yeah, I think having a new dependency type would make a lot of
sense, I'd propose a different name though, something like
"PropagateReload=" where all service which to propagate reload to may be
If I understand this correctly you are planning to support multiple
simultaneous instances of these sandboxed services? May I suggest using
systemd instanced services for that? That way the instances would show
up as individual services in systemd and can be handled like any other
To make this entirely convincing we'd need a way to allow
stopping/restarting/... all instances of a certain kind at once though,
which currently doesn't exist. (example, let's say you have
sandboxed-apache at foobar.service, sandboxed-apache at waldo.service and so
on, and when sandboxed-apache.rpm is removed you want to ensure that all
these instances are stopped, we need a sane way to stop them all at
once, instead of having to figure out which instances are running and
then stop them indivudally). To make this easy I'll extend the D-Bus
logic a bit so that "systemctl stop quux at .service" (i.e. without an
instance part in the name) will stop all instances of that template.
I added this to the TODO list now, both should be available in not so
long time from now, as they aren't hard to implement.
Thanks for your suggestions!
Lennart Poettering - Red Hat, Inc.
More information about the systemd-devel