Bug 665178 – net-misc/sslh: sslh-fork.c:110:connect: Connection refused

• Product: Gentoo Linux
• Status: CONFIRMED ---

[Description Thomas Deutschmann (RETIRED) 2018-09-03 16:36:56 UTC]

I started to play with net-misc/sslh-1.19c for the first time and a basic configuration like

> DAEMON_OPTS="--listen 192.168.0.44:80 --ssh 127.0.0.1:22 --http 127.0.0.1:80 --user nobody"

Will cause 

> sslh-fork.c:110:connect: Connection refused
> sslh-fork.c:110:connect: Connection refused
> sslh-fork.c:110:connect: Connection refused
> sslh-fork.c:110:connect: Connection refused
> sslh-fork.c:110:connect: Connection refused
> sslh-fork.c:110:connect: Connection refused
> sslh-fork.c:110:connect: Connection refused
> sslh-fork.c:110:connect: Connection refused
> sslh-fork.c:110:connect: Connection refused

output in the terminal where I started the service (/etc/init.d/sslh start) once someone hit http://192.168.0.44 when nothing is running yet at 127.0.0.1:80.

I guess service has to close fd and should log errors like that to normal syslog.

[Comment 1 Thomas Deutschmann (RETIRED) 2018-09-03 16:39:39 UTC]

Adding

> command_background="yes"

to the runscript is doing the trick.

[Comment 2 Thomas Deutschmann (RETIRED) 2018-09-03 17:14:39 UTC]

I am not yet really happy with it. I created a configuration file an updated DAEMON_OPTS to use "-F/etc/sslh.cfg". I had a syntax error in my config file but runscript didn't detect that sslh died after start. You normally add something like

> start_stop_daemon_args="--wait 1000"

in that case. But doing that won't work due to

>  * start-stop-daemon: caught an interrupt

which is clashing with the way OpenRC is forcing the service into background.

Removing 'command_background' instead and force "--background" as DAEMON_OPTS doesn't work like expected, i.e. sslh doesn't close fd like expected so you will still get any output on the terminal where you started that service.

Using "--foreground" requires "command_background" but will prevent any output, including syslog :/

[Comment 3 Andreas Sturmlechner 2022-09-15 17:42:24 UTC]

Is this bug still relevant with 1.22c?