Bill Carney's picture
Bill Carney - Mon, 2019/12/02 - 23:30

Issue: There is a Python task is holding on to port 80 after rebooting.

Cause:

I restored a tklbam-backup to a new server.

I followed the Confconsole - Let's Encrypt fix instructions here, and it worked as expected.

I ran /usr/lib/confconsole/plugins.d/Lets_Encrypt/dehydrated-wrapper to grab updated certificates since the old ones were moved to Dehydrated.bak as part of the update.

It crashed, never finishing the script. The cause was because I had a domain that I no longer host listed in /etc/dehydrated/confconsole.domains.txt AND the site was still enabled in Apache.

Because it crashed, the task never relinquished control over port 80.

So I rebooted.  But Apache won't start.

The only way to get Apache back up is to manually run /usr/lib/confconsole/plugins.d/Lets_Encrypt/dehydrated-wrapper again.

That works - sometimes.  Other times I get 

root@lamp ~# /usr/lib/confconsole/plugins.d/Lets_Encrypt/dehydrated-wrapper
[2019-12-02 00:20:44] dehydrated-wrapper: INFO: started
[2019-12-02 00:20:45] dehydrated-wrapper: INFO: found python listening on port 80
[2019-12-02 00:20:45] dehydrated-wrapper: FATAL: An unknown Python app is listening on port 80
[2019-12-02 00:20:45] dehydrated-wrapper: WARNING: Python is still listening on port 80
[2019-12-02 00:20:45] dehydrated-wrapper: INFO: attempting to kill add-water server
[2019-12-02 00:20:45] dehydrated-wrapper: WARNING: Something went wrong, restoring original cert & key.
[2019-12-02 00:20:45] dehydrated-wrapper: INFO: starting stunnel4
[2019-12-02 00:20:45] dehydrated-wrapper: WARNING: Check today's previous log entries for details of error.

 

But eventually whatever Python task is running stops/times out, and I'm able to run  /usr/lib/confconsole/plugins.d/Lets_Encrypt/dehydrated-wrapper which then allows me to manually start Apache, but obviously this isn't ideal.

Any thoughts on what Python task is running at startup and how to get it to stop?

 

Forum: 
Support
Tags: 
apache
dehydrated
Jeremy Davis's picture

Jeremy Davis - Mon, 2019/12/02 - 23:38

That appears to be an unintended consequence of the Let's Encrypt fix. The way we worked around the race condition was by providing our add-water challenge server as a systemd service. However it appears that it is being automatically enabled to start at boot (that shouldn't be...). We'll have to have a closer look and see why that is occurring, but in the meantime:

systemctl stop add-water
systemctl disable add-water

Once you'v done that, it should start/stop when required, but never auto-start.

Jeremy Davis's picture

Jeremy Davis - Wed, 2019/12/04 - 05:40

So long as you have run "systemctl disable add-water" there is no need to install the latest v1.1.2 Confconsole update. That's because it's exactly the same as v1.1.1, but with the add-water service not enabled to auto start when installed. It doesn't explicitly disable the service though, so it has no value for people who have already run the previous update (you still need to manually disable add-water if you installed v1.1.1).

However, for users who haven't yet updated, the newer version is recommended (as it removes the need to manually disable the add-water service). So even though it's irrelevant to you, I thought it worth noting here just in case someone else stumbles across this thread looking for a solution...

Add new comment