Closed emeidi closed 3 years ago
Go by your theory, if Monit's https requests causing the crash, you would be able to capture the details of the request with tcpdump.
pixelserv-tls with log level 2 or below is very robust from my tests. Once you increase log level to capture the full URL, the robustness decreases. It's because today's advertisers & trackers are simply crazy uploading huge size of info to their servers. It's not uncommon to see a few crashes per week.
I'm an Arch user. A little out of loop with Debian. If systemd is available, its 'restart always' is a very good keepalive feature.
Today I moved my pixelserv-tls instance 2.2.1 from a Debian server to another Debian server running (
Linux MYSERVER 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64 GNU/Linux
). Shortly after the switch syslog started to fill with segfaults like the one below, occuring every few minutes:I first updated to 2.3.1 to make sure this bug wasn't already fixed in a newer version. But the crashes continued to happen.
I use monit to detect pixelserv-tls crashing, so it got restarted automatically everytime this happened. I set this up as a precaution because less mature versions of pixelserv-tls used to crash a lot, or even though the process was running, no requests were served anymore.
I then used strace to debug a running process right before the crash:
I also increased the debug level to 5:
Why is pixelserv-tls receiving requests from the same host? This is when it dawned to me that my monit HTTPS check running on he same machine actually might cause the issue:
(I am running
monit 1:5.26.0-4
).Preliminary conclusion: The way monit's HTTPS requests are formed makes pixelserv-tls segfaulting.
I have now changed the monit configuration to the following, and no segfaults have happened so far: