You can also create a /lib/systemd/systemd/my_main_script.service
and use "ln -s /lib/systemd/system/my_main_script.service
/etc/systemd/system/uniq1.service". Then use "mkdir
/etc/systemd/system/uniq1.service.d" and create a
/etc/systemd/system/uniq1.service.d/blah.conf that has systemd.unit
things that override the main my_main_script.service.
On 10/14/15 9:01 PM, Stuart Longland
wrote:
On 15/10/15 13:23, Andrei Borzenkov wrote:
15.10.2015 00:30, Stuart Longland пишет:
Assuming I have a few files distributed in the base package:
/lib/systemd/system/comms-drivers.service
/lib/systemd/system/comms-drivers@.service
Ordinarily, one would tell systemd about template instances by creating
symbolic links.
Suppose however I wanted to not do this, but instead, provide some
automatic discovery mechanism for systemd, so it could run a script that
would tell it what instances exist.
Is there a mechanism for doing this in systemd?
I'm not sure if I actually understand the question, but - templates are
instantiated on the fly. If template foo@.service exists and it is
attempted to start foo@bar.service, systemd will create it internally.
It is full fledged unit that is visible in status, can be stopped, is
part of dependency resolution etc.
Okay, that's useful to know. So in order to start foo@bar.service, I
don't need to create any files.
Question is, how does systemd find out about the existence of
foo@bar.service without a file being present?
The idea being that the service foo.service acts as a means of
starting/stopping/querying all instances. I would guess that
stopping/restarting/querying, systemd is smart enough to look at what's
presently running, however what about starting?
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
|
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
