On Tue, 10.01.12 10:19, Daniel J Walsh ([email protected]) wrote: > > 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.
Hmm, makes sense. Internally we have to have those dependencies in both ways anyway, so it would definitely make sense to have ReloadPropagatedFrom= in addition to PropagateReloadTo= or so. > 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 Yes. Most likely you don't even have to create the file /etc/systemd/system/[email protected] at all, instead just symlink it from /lib/systemd/system/[email protected], i.e. the common template. > systemctl stop [email protected] > > Would stop httpd.service, [email protected] and > [email protected] Almost. It will stop the instanced services, but not the one that isn't instantiated. You'd have to use this instead: Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
