What I found for quantum holds for keystone and nova. My twisted logic says "what holds for some, surely holds for all"... so I am filling this general bug. +++ This bug was initially created as a clone of Bug #972359 +++ Description of problem: quantum fails and there is nothing in the log if there is [SECURITYGROUP] # Firewall driver for realizing quantum security group function quantum.agent.linux.iptables_firewall.IptablesFirewallDriver in the /etc/quantum/plugin.ini, then quantum doesn't start and doesn't output anything to server.log Version-Release number of selected component (if applicable): openstack-quantum-2013.1.1-10.el6ost.noarch openstack-quantum-linuxbridge-2013.1.1-10.el6ost.noarch How reproducible: always Steps to Reproduce: 1. change the config accordingly to description 2. restart quantum-server 3. Actual results: quantum is dead, nothing in log. Expected results: error in log Additional info: --- Additional comment from Ryan O'Hara on 2013-06-11 02:33:32 CEST --- How did you install? Can you attach the plugin.ini file? --- Additional comment from Jaroslav Henner on 2013-06-11 14:22:19 CEST --- (In reply to Ryan O'Hara from comment #1) > How did you install? Can you attach the plugin.ini file? With broken Packstack (see the referred clone of this bug), but you can simulate it without the packstack, with the RPMs for sure. Obviously, the bug won't appear with Devstack because Devstack IMHO doesn't use the init scripts. I don't have that config, but you should be able to reproduce it: [root@master-02 ~]# echo 'I am evil as hell.' >> /etc/quantum/plugin.ini [root@master-02 ~]# tail -fn0 /var/log/quantum/linuxbridge-agent.log & [2] 16976 [root@master-02 ~]# /etc/init.d/quantum-linuxbridge-agent restart Stopping quantum-linuxbridge-agent: [ OK ] Starting quantum-linuxbridge-agent: [ OK ] [root@master-02 ~]# /etc/init.d/quantum-linuxbridge-agent status quantum-linuxbridge-agent dead but pid file exists [root@master-02 ~]# kill % [root@master-02 ~]# See? No message. Only death.
*** Bug 973328 has been marked as a duplicate of this bug. ***
*** Bug 972359 has been marked as a duplicate of this bug. ***
Note it is possible to debug the invalid conf if one knows does the init spawn the service process: [root@folsom-rhel6 ~]# echo 'Evil line' >> /etc/keystone/keystone.conf [root@folsom-rhel6 ~]# /usr/bin/python /usr/bin/keystone-all --config-file /usr/share/keystone/keystone-dist.conf --config-file /etc/keystone/keystone.conf Traceback (most recent call last): File "/usr/bin/keystone-all", line 82, in <module> default_config_files=config_files) File "/usr/lib/python2.6/site-packages/oslo/config/cfg.py", line 1182, in __call__ self._parse_config_files() File "/usr/lib/python2.6/site-packages/oslo/config/cfg.py", line 1653, in _parse_config_files raise ConfigFileParseError(pe.filename, str(pe)) oslo.config.cfg.ConfigFileParseError: Failed to parse /etc/keystone/keystone.conf: at /etc/keystone/keystone.conf:227, No ':' or '=' found in assignment: 'Evil line'
This bug appears also when there are problems with permission when reading the config files. Rising severity because this is really nasty. I had to debug with strace -f to see why my quantum-linuxbridge-agent doesn't start
Created attachment 879008 [details] openstack-nova-api.patch This is not a issue on upstream: https://bugs.launchpad.net/oslo/+bug/1190001 It is either, depending on point of view: * a bug in the init scripts, or it is * the config parsing is not reporting to the log because the logging is initialized after the config parsing (which makes sense because you can configure logging there). Check how the init script behaves when it is not dumping the outputs to a sewage (apply the attached patch). [root@jhenner-node-permanent-1 ~]# /etc/init.d/openstack-nova-api restart Stopping openstack-nova-api: [FAILED] Starting openstack-nova-api: [ OK ] [root@jhenner-node-permanent-1 ~]# /etc/init.d/openstack-nova-api.modified restart Stopping openstack-nova-api: [FAILED] Starting openstack-nova-api: Traceback (most recent call last): File "/usr/bin/nova-api", line 10, in <module> sys.exit(main()) File "/usr/lib/python2.6/site-packages/nova/cmd/api.py", line 40, in main config.parse_args(sys.argv) File "/usr/lib/python2.6/site-packages/nova/config.py", line 37, in parse_args default_config_files=default_config_files) File "/usr/lib/python2.6/site-packages/oslo/config/cfg.py", line 1636, in __call__ else sys.argv[1:]) File "/usr/lib/python2.6/site-packages/oslo/config/cfg.py", line 2137, in _parse_cli_opts return self._parse_config_files() File "/usr/lib/python2.6/site-packages/oslo/config/cfg.py", line 2151, in _parse_config_files ConfigParser._parse_file(config_file, namespace) File "/usr/lib/python2.6/site-packages/oslo/config/cfg.py", line 1256, in _parse_file raise ConfigFileParseError(pe.filename, str(pe)) oslo.config.cfg.ConfigFileParseError: Failed to parse /etc/nova/nova.conf: at /etc/nova/nova.conf:3494, No ':' or '=' found in assignment: 'I am evil as hell.'
> * a bug in the init scripts, or it is This should be fixed as a part of bug 1036515 where startup messages are redirected to the separate startuplog /var/log/$prog/$prog-startup.log
comment 11 applies for el6 For el7 systemd services output is collected by the systemd journal.