-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/09/2012 09:38 PM, Lennart Poettering wrote: > On Mon, 09.01.12 16:42, Daniel J Walsh ([email protected]) 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 also. >> >> 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 listed. > Well I would prefer to have my services request Reloads destined for a particular service, rather then updating an existing service file to add my new services.
> 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 service: > > http://0pointer.de/blog/projects/instances.html > I will look into this. > 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 [email protected], > [email protected] 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 [email protected]" (i.e. > without an instance part in the name) will stop all instances of > that template. > So if I have a sandboxed version of httpd.server, you would want me to name them [email protected]? # virt-sandbox-service create -e /usr/sbin/httpd sandbox1 Created container dir /var/lib/libvirt/filesystems/sanbox1 Created sandbox config /etc/libvirt-sandbox/sandbox1.sandbox Created unit file /etc/systemd/system/[email protected] # virt-sandbox-service create -e /usr/sbin/httpd sandbox2 Created container dir /var/lib/libvirt/filesystems/sanbox2 Created sandbox config /etc/libvirt-sandbox/sandbox2.sandbox Created unit file /etc/systemd/system/[email protected] Then you could say systemctl stop [email protected] Would stop httpd.service, [email protected] and [email protected] > 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 > Not one of the other comments in this chain was asking about bindto, which I don't want. I want to allow an admin to run my services without running httpd.service for example. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8MVvQACgkQrlYvE4MpobOhwACfeq/+8K48wnYT6nhX69mvZYAX rHAAn0C7fznj02ri0UqKO1cBKRFDB4fJ =42KA -----END PGP SIGNATURE----- _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
