Red Hat Bugzilla – Bug 448188
does not notice event file removals
Last modified: 2014-06-18 04:46:26 EDT
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
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?