openshift / geard

geard is no longer maintained - see OpenShift 3 and Kubernetes

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Starting the daemon with systemd behaves differently than running in shell

davidpelaez opened this issue · comments

Hi.

I have a very strange behaviour that I haven't manage to understand. When I run as root this:

/usr/bin/gear daemon --has-env-file --listen-address='127.0.0.1:43273'

Everything works as expected: The daemon binds to the loopback in the specified port.

However if I use this service unit:

[Unit]
Description=Gear Provisioning Daemon (geard)

[Service]
ExecStart=/usr/bin/gear daemon --has-env-file --listen-address='127.0.0.1:43273'

[Install]
WantedBy=multi-user.target

I always get a failing status:

May 27 13:08:37 ferry systemd[1]: Starting Gear Provisioning Daemon (geard)...
May 27 13:08:37 ferry systemd[1]: Started Gear Provisioning Daemon (geard).
May 27 13:08:37 ferry gear[9883]: Listening (HTTP) on '127.0.0.1:43273' ...
May 27 13:08:37 ferry gear[9883]: listen tcp: unknown port tcp/43273'
May 27 13:08:37 ferry systemd[1]: geard.service: main process exited, code=exited, status=1/FAILURE

When the listen-address flag is entirely removed, everything works in systemd:

May 27 13:12:28 ferry systemd[1]: Starting Gear Provisioning Daemon (geard)...
May 27 13:12:28 ferry systemd[1]: Started Gear Provisioning Daemon (geard).
May 27 13:12:28 ferry gear[10850]: Listening (HTTP) on :43273 ...

But this leaves the daemon http interface exposed to all interfaces, which I really don't want for security reasons. Instead I want to expose the API to use from local apps through HTTP. I don't see what I'm doing wrong. First I thought it was an issue of compiling with contrib/build -s then I disabled that flag and I still cannot get it running only attached to the loopback.

Ok. This is almost embarrassing ¬¬. The problem was the quoting of the address. Using as reference https://github.com/openshift/geard/blob/master/contrib/geard.defaults I had the address in single quotes, which I assume, would be used only for grouping in the ExecStart and never arrive quoted to the flag parser. But since I'm writing the value with quotes directly in the unit, it's being passed. The solution was to use:

ExecStart=/usr/bin/gear daemon --has-env-file --listen-address=127.0.0.1:43273, instead of:
ExecStart=/usr/bin/gear daemon --has-env-file --listen-address='127.0.0.1:43273'