Ошибка SSL только при работе systemd

Я отправил более широкий вопрос на StackOverflow, но я думаю, что некоторые проблемы являются, вероятно, очень определенными для человечности.

Я пытаюсь выполнить logstash на экземпляре aws ec2 рабочая человечность 16.04 с помощью systemd. Выполнение конвейера обычно (с помощью bin/logstash.bat) хорошо работает, и события поглощены.

Но когда я пытаюсь выполнить сервис на systemd, я получаю ошибки, из которых первой является ошибка SSL:

Error: no cipher match (OpenSSL::SSL::SSLError)

[2017-02-15T13:08:44,037][ERROR][logstash.pipeline        ] A plugin
had an unrecoverable error. Will restart this plugin.   
Plugin:
<LogStash::Inputs::Heroku app=>"xxxxxx",
codec=><LogStash::Codecs::Multiline pattern=>"^%{TIMESTAMP_ISO8601}
%{WORD}\\[\\w+(\\.\\d+)?\\]:(\\s{3,}| \\})", what=>"previous",
id=>"032c3b317ae49982945ec7e8fbf11224be98f237-3", enable_metric=>true,
negate=>false, charset=>"UTF-8", multiline_tag=>"multiline",
max_lines=>500, max_bytes=>10485760>,
id=>"032c3b317ae49982945ec7e8fbf11224be98f237-4", enable_metric=>true>

Я попытался выполнить сервис как корень, но результатом является то же. Просто для уточнения это работает:

/usr/share/logstash/bin/logstash --path.settings /etc/logstash/

В то время как это не делает:

sudo systemctl start logstash

Это - чистая установка logstash 5.2.1 выполнения процедур на резинке. Systemd также выполняется согласно их процедурам, так, чтобы он выполнил ту же команду, как я выполняюсь вручную. cat logstash.service вывод:

[Unit]
Description=logstash

[Service]
Type=simple
User=logstash
Group=logstash
# Load env vars from /etc/default/ and /etc/sysconfig/ if they exist.
# Prefixing the path with '-' makes it try to load, but if the file doesn't
# exist, it continues onward.
EnvironmentFile=-/etc/default/logstash
EnvironmentFile=-/etc/sysconfig/logstash
ExecStart=/usr/share/logstash/bin/logstash "--path.settings" "/etc/logstash"
Restart=always
WorkingDirectory=/
Nice=19
LimitNOFILE=16384

[Install]
WantedBy=multi-user.target

(результатом является то же, когда я комментирую пользователя и группу выше),

Править: Таким образом, кажется, что SSL мог бы быть вызван другой ошибкой, которую я получаю. Я выследил обоих журнал сервисного использования sudo journalctl -f -u logstash & и журналы самого сервиса в фоновом режиме и получили следующий вывод:

ubuntu@ip-10-0-1-216$:~ sudo systemctl запускают logstash

ubuntu@ip-10-0-1-216$:~ 15 февраля 15:38:19 ip-10-0-1-216 systemd1: Запущенный logstash.

15 февраля 15:38:33 ip-10-0-1-216 logstash [5119]: Отправка журналов Logstash к/var/log/logstash, который теперь настроен через log4j2.properties

15 февраля 15:38:36 ip-10-0-1-216 logstash [5119]: Введите свои учетные данные Heroku.

15 февраля 15:38:36 ip-10-0-1-216 logstash [5119]: электронная почта: Пароль (ввод будет скрыт):

15 февраля 15:38:36 ip-10-0-1-216 logstash [5119]: Введите свои учетные данные Heroku.

15 февраля 15:38:36 ip-10-0-1-216 logstash [5119]: электронная почта: Пароль (ввод будет скрыт):

15 февраля 15:38:36 ip-10-0-1-216 logstash [5119]: Введите свои учетные данные Heroku.

15 февраля 15:38:36 ip-10-0-1-216 logstash [5119]: электронная почта: Пароль (ввод будет скрыт):

15 февраля 15:38:36 ip-10-0-1-216 logstash [5119]: Введите свои учетные данные Heroku.

15 февраля 15:38:36 ip-10-0-1-216 logstash [5119]: электронная почта: Пароль (ввод будет скрыт):

[2017-02-15T15:38:37,403] [ОШИБКА] [logstash.pipeline] плагин имел неисправимую ошибку. Перезапустит этот плагин. Плагин: "ros-prd", кодек => "^ % {TIMESTAMP_ISO8601} % {WORD }\\[\w + (\.\d +)? \] :( \s {3} | \})", что => "предыдущий", идентификатор => "9fd55a86d7f6e98e9c1698eb67a66a24364ea902-3", enable_metric => верный, инвертирует => ложь, набор символов => "UTF-8", multiline_tag => "мультилиния", max_lines => 500, max_bytes => 10485760>, идентификатор => "9fd55a86d7f6e98e9c1698eb67a66a24364ea902-4", enable_metric => верный>

Таким образом, похоже, что ошибка SSL только начинает после подсказок вводить heroku пароль.

Так мой вопрос (вопросы):

1. Похоже, что heroku учетные данные хранятся в ~/home/user/.netrc. Как я могу предоставить systemd услугу с с доступом к этому файлу так, чтобы это не запрашивало heroku пароль?
2. Или, если вышеупомянутое не возможно, как я могу передать пароль службе? Там некоторый путь состоит в том, чтобы усилить systemd-tty-ask-password-agent, возможно?