On Monday 17 June 2019 04:34:38 Axel Beckert wrote: > Control: tag -1 + unreproducible moreinfo > Control: severity -1 important > > Hi Pali, > > Pali Rohár wrote: > > severity 919188 critical > > Why? You neither explained that it breaks the whole system nor that it > causes other, unrelated packages to break nor that it causes serious > data-loss. > > Please check https://www.debian.org/Bugs/Developer#severities and > explain why you think that the severity you've chosen fits this bug > report.
Hi! The reason is that it breaks boot process. startpar is still running and sslh stdout output is going to tty1 where /dev/console points. > I'm neither the package maintainer nor a release team member (just a > happy sslh user), but this bug is at most "grave" even according to > your description. > > Addtionally I can't reproduce this bug no matter which variant I'm > trying. And I'm running sslh under sysvinit on Debian Testing since > 2012 (in standalone and single-thread mode): Strange, it happens for me on all Debian servers where sslh is installed and in use. Also exactly same problem is on small Raspberry PI installation. And proposed fix fixes it... Some maybe configuration of something other takes effect on it too? For me it is 100% reproducible, no race condition or randomness. > # ps auxf | fgrep sslh > root 24116 0.0 0.0 8472 908 pts/1 S+ 03:08 0:00 | \_ grep > -F sslh > sslh 12185 0.0 0.2 14004 2648 ? Ss May07 2:49 > /usr/sbin/sslh-select --user sslh --listen 0.0.0.0 443 --ssh 127.0.0.1 22 > --ssl 127.0.0.1 442 --pidfile /var/run/sslh/sslh.pid > # dpkg -l sysvinit-core startpar > Desired=Unknown/Install/Remove/Purge/Hold > | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > ||/ Name Version Architecture Description > +++-==============-============-============-================================= > ii startpar 0.61-1 amd64 run processes in parallel and > multiplex their output > ii sysvinit-core 2.93-8 amd64 System-V-like init utilities > # lsb_release -a > No LSB modules are available. > Distributor ID: Debian > Description: Debian GNU/Linux 10 (buster) > Release: 10 > Codename: buster > # uptime > 03:13:44 up 94 days, 2:26, 2 users, load average: 0,03, 0,23, 0,65 > # > > The above is from before a reboot, but I just rebooted and there's > still only one sslh-select process. Tried "service sslh stop" and > "service sslh start" as well as rebooting. No difference, no issue. I > also tried using the forked variant instead of the single-thread I > used so far. But still, neither stopping and starting nor rebooting > showed a hanging startpar. Here's after the switch to the forked > version and two reboots: > > # ps auxf | fgrep sslh > root 2791 0.0 0.0 8476 908 pts/1 S+ 03:49 0:00 > \_ grep -F sslh > sslh 2515 0.0 0.1 4760 1660 ? Ss 03:47 0:00 > /usr/sbin/sslh --user sslh --listen 0.0.0.0 443 --ssh 127.0.0.1 22 --ssl > 127.0.0.1 442 --pidfile /var/run/sslh/sslh.pid > sslh 2518 0.0 0.0 4760 176 ? S 03:47 0:00 \_ > /usr/sbin/sslh --user sslh --listen 0.0.0.0 443 --ssh 127.0.0.1 22 --ssl > 127.0.0.1 442 --pidfile /var/run/sslh/sslh.pid > # > > Hence tagging it as unreproducible and downgrading the severity: > > Since this issue doesn't even "rendering it completely unusable" for > all sysvinit users (which is considered to be "serious" or "grave") > nor for either sslh or sslh-select, this is at most "a bug which has a > major effect on the usability of a package, without rendering it > completely unusable to everyone.", i.e. severity "important". > > And please also show the complete options to sslh, because this > behaviour could e.g. stem from using the -i (inetd) option (which is > meant to listen on STDIN and sending to STDOUT) together with starting > sslh via init script. If that's the case, it's a configuration error > and no bug. (Except maybe that it should listen on port 443 at all > then. :-) It is standalone configuration, no inetd is involved. > But even if I configure sslh for both, inetd and as a standalone > service, this issue does not happen since the standalone service fails > to start because inetd already occupies the HTTPS port. > > So please also show your sslh entry in /etc/inetd.conf and your > /etc/default/sslh. $ cat /etc/inetd.conf cat: /etc/inetd.conf: No such file or directory $ cat /etc/default/sslh # Default options for sslh initscript # sourced by /etc/init.d/sslh # Disabled by default, to force yourself # to read the configuration: # - /usr/share/doc/sslh/README.Debian (quick start) # - /usr/share/doc/sslh/README, at "Configuration" section # - sslh(8) via "man sslh" for more configuration details. # Once configuration ready, you *must* set RUN to yes here # and try to start sslh (standalone mode only) RUN=yes # binary to use: forked (sslh) or single-thread (sslh-select) version # systemd users: don't forget to modify /lib/systemd/system/sslh.service DAEMON=/usr/sbin/sslh DAEMON_OPTS="--user sslh --transparent --listen MYDOMAIN:443 --ssh localhost:22 --http localhost:80 --ssl localhost:443 --pidfile /var/run/sslh/sslh.pid" > Hence also tagging as "moreinfo". As it happens on all my Debian systems, I thought that it is easily reproducible. But seems that there must be something else which is causing this problem if you are not able to reproduce it. At least my proposed patch fixes this problem. > The only (IMHO minor) bug I could find is that "dpkg-reconfigure sslh" > doesn't seem to edit neither /etc/inetd.conf nor /etc/default/sslh to > switch between the two variants. But if the initial configuration > works fine, I'd consider that to be of severity "normal" at most if > not just "minor". > > Regards, Axel -- Pali Rohár [email protected]
