The command "telinit q" does not cause a reload of the configuration. I believe that for compatibility with the old SysV Init it should work, I would like to be able to remove files from /etc/event.d/ and then run "telinit q" to cause the services in question to be stopped. But if upstart is not going to implement such functionality then the command "telinit q" should display an error message explaining the situation and return a value other than zero.
Upstart monitors files in /etc/event.d thus obviating the need for the functionality provided by 'telinit q'
Actually I was stupid - this shouldn't be closed, rather the implementation should either be removed from telinit, or it should produce an informative message to this effect.
The file monitoring doesn't seem to work well. When I moved the files in question to another directory in an attempt to disable the gettys nothing happened.
Hm, I'm not sure what the upstream algorithm is - what you want is for any removed event file to cause that job to be stopped?
System administrators who have become used to the SysVinit functionality will expect that when they change the init config file (/etc/inittab) and run "telinit q" they will have their changes applied. If upstart correctly noticed changes (according to the description in comment #1) then they would be applied before the sysadmin could run "telinit q", this would be a problem for someone who edits files and then wants to apply the changes later (EG changing config files before a change window officially opens). A warning would still be required. The current situation (according to my tests) is that I change the files, run "telinit q" and nothing happens. Anything other than the current situation would be an improvement.
Running jobs in upstart do not receive configuration changes. You must stop and restart the individual jobs for configuration to change.
Will anyone vouch for keeping this open?
Guess not.