A job has many attributes like restartability, resource limitations,
and I am sure this will grow over time.
Right now, once a job is defined the way to update it is to update the
job file and Upstart will reload it.
I was wondering about the following questions,
1. When a job file gets updated and reloaded, how does it affect the
behavior of existing instances of the job. Say I modified the
restartability field and disable restarts. Will it affect the job
instance that was started before the job file modification? How is the
new job file, related to what used to be.
2. Would it make sense to have D-Bus client API change modify some of
the attributes of a job or job instance in memory without modifying the
job file on disk?
These questions come up when trying to figure out how to bridge System
Management/Configuration affect job files, jobs or job instances.
Many of the job files will never be affected by configuration. But I
suspect there will be a class of jobs that may have an initial
definition during installation but may be affected by configuration.
Some of these changes may be temporary in that it may not survive a
system restart and some of these configurations may be saved and might
need to survive a system restart.
How do we do this? I have some thoughts/options on how these could be
done. But I wanted to check if this has been discussed before and what
the community is thinking.
Sari
--
upstart-devel mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/upstart-devel
