Closed metakermit closed 8 years ago
The error means, that node wanted to read from a file but at the path there was a directory. Maybe users.json was missing and then mounted as directory in the container?
On Tue, Feb 2, 2016 at 1:50 PM, Dražen Lučanin notifications@github.com wrote:
Result of running blimp-upgrade.sh for the first time on a cleaned out blimp. Not really sure what Error: EISDIR, illegal operation on a directory might indicate – maybe an invalid path because I cleaned out /opt/cloudfleet/data/ manually, wasn't starting from the results of the Ansible playbook runs. The other containers were started normally.
blimp_doveshed_1 loglevel: LOGPROTOCOL Starting up Haraka version 2.6.1 [INFO] [-] [core] Loading plugins [INFO] [-] [core] Loading plugin: queue/smtp_forward [DEBUG] [-] [core] no timeout in queue/smtp_forward.timeout [DEBUG] [-] [core] no timeout in plugin_timeout [DEBUG] [-] [core] plugin queue/smtp_forward timeout is: 30s [DEBUG] [-] [core] Returning boolean true for main.enable_tls=true [DEBUG] [-] [core] registered hook queue to queue/smtp_forward.hook_queue [DEBUG] [-] [core] registered hook queue_outbound to queue/smtp_forward.hook_queue_outbound [INFO] [-] [core] Loading plugin: relay_all [DEBUG] [-] [core] no timeout in relay_all.timeout [DEBUG] [-] [core] no timeout in plugin_timeout [DEBUG] [-] [core] plugin relay_all timeout is: 30s [ERROR] [-] [relay_all] deprecated. see 'haraka -h relay' [DEBUG] [-] [core] registered hook rcpt to relay_all.confirm_all [INFO] [-] [core] Loading plugin: tls [DEBUG] [-] [core] no timeout in tls.timeout [DEBUG] [-] [core] no timeout in plugin_timeout [DEBUG] [-] [core] plugin tls timeout is: 30s [CRIT] [-] [core] Error: EISDIR, illegal operation on a directory [CRIT] [-] [core] at Object.fs.readSync (fs.js:476:19) [CRIT] [-] [core] at Object.fs.readFileSync (fs.js:315:28) [CRIT] [-] [core] at Object.cfreader.load_binary_config (/usr/local/lib/node_modules/Haraka/configfile.js:499:23) [CRIT] [-] [core] at Object.cfreader.load_config (/usr/local/lib/node_modules/Haraka/configfile.js:228:31) [CRIT] [-] [core] at Object.cfreader.read_config (/usr/local/lib/node_modules/Haraka/configfile.js:155:27) [CRIT] [-] [core] at Object.config.get (/usr/local/lib/node_modules/Haraka/config.js:15:28) [CRIT] [-] [core] at Plugin.exports.load_pem (/usr/local/lib/node_modules/Haraka/plugins/tls.js:38:26) [CRIT] [-] [core] at Plugin.exports.register (/usr/local/lib/node_modules/Haraka/plugins/tls.js:15:21) [CRIT] [-] [core] at Object.plugins._register_plugin (/usr/local/lib/node_modules/Haraka/plugins.js:197:12) [CRIT] [-] [core] at plugins.load_plugin (/usr/local/lib/node_modules/Haraka/plugins.js:122:17) [NOTICE] [-] [core] Shutting down — Reply to this email directly or view it on GitHub https://github.com/cloudfleet/doveshed/issues/1.
Good point. The issue was that the _tlskey.pem and _tlscert.pem files in /opt/cloudfleet/data/shared/tls/ were actually folders (users.json was there), related to the docker mounting behaviour you described.
The files were missing because Spire was down due to a weird ctypes error (don't know why it started happening right now – maybe some OS upgrade brought us a broken Python version). Solved it for now by upgrading to Python 3.5 as I explained in this SO answer (and I made a comment in base-builder).
Result of running blimp-upgrade.sh for the first time on a cleaned out blimp. Not really sure what
Error: EISDIR, illegal operation on a directory
might indicate – maybe an invalid path because I cleaned out /opt/cloudfleet/data/ manually, wasn't starting from the results of the Ansible playbook runs. The other containers were started normally.