Stopped it and it completely stopped serving all pages, started it again.
With no way to bug test this (because I think we all see the cert working), I can only guess at this point. GAH!
Stopped it and it completely stopped serving all pages, started it again.
With no way to bug test this (because I think we all see the cert working), I can only guess at this point. GAH!
Ideally you would check it via something like:
ps aux | grep -i apache
[while you had it "stopped" to insure no apache was left running]
Also, applications such as htop
in "tree" mode or pstree
might shed some light on buggy Apache restarts.
For example, if I run:
pstree -pu $(cat /var/run/apache2.pid)
I get a tree of my root started Apache application (from the PID file) with the two child processes running as apache
and their threads in the third column. The -p
options specifies to output the PIDs of all the processes and threads.
Now, if your server isn't that active, the amount of processes wouldn't differ that much.. If you run the above command, reload your Apache and run the command again after the reload, you could compare the two outputs and see if one of the old processes is staying around, when it shouldn't!
Note that when doing a graceful restart, the processes are actually allowed to finish their current connections. However, it might be a buggy process keeps lingering around for waaaaayyy too long. You could detect this with tools like pstree
.
I believe this is where Apache fails.
If any single process can handle a very large number of clients that time could take a long while.
If during that time it loses track that it was not supposed to accept any new connections it might start accepting them and continue waiting until all have stopped.
Which won't ever happen (on a busy system) because it continues to add in new ones!
And again, this will most often go completely unnoticed because old and new are identical.
I'm not seeing any repeats:
─apache2(71547)─┬─apache2(72269,www-data)
│ ├─apache2(72406,www-data)
│ ├─apache2(72427,www-data)
│ ├─apache2(72429,www-data)
│ ├─apache2(72431,www-data)
│ ├─apache2(72444,www-data)
│ ├─apache2(72451,www-data)
│ ├─apache2(72459,www-data)
│ ├─apache2(72501,www-data)
│ ├─apache2(72502,www-data)
│ ├─apache2(72503,www-data)
│ ├─apache2(72506,www-data)
│ ├─apache2(72507,www-data)
│ ├─apache2(72508,www-data)
│ ├─apache2(72512,www-data)
│ ├─apache2(72515,www-data)
│ ├─apache2(72516,www-data)
│ ├─apache2(72517,www-data)
│ ├─apache2(72518,www-data)
│ ├─apache2(72519,www-data)
│ ├─apache2(72520,www-data)
│ └─apache2(72522,www-data)
Restarted Apache2, new results:
├─apache2(72613)─┬─apache2(72621,www-data)
│ ├─apache2(72622,www-data)
│ ├─apache2(72623,www-data)
│ ├─apache2(72624,www-data)
│ ├─apache2(72625,www-data)
│ └─apache2(72627,www-data)
What do you mean with "repeats" in this output? There can never be a multiple of PIDs at the same time, so a repeat in a single output is out of the question anyway.
One tree is before restart
One is after restart.
None of the numbers are repeated.
[from tree to tree]
@Osiris do you speak English or English? LOL
Ah, looking at the "├" mark near the bottom part of the output, I thought it was a single output with the "├" marking the second process.
Also note that it might be this bug doesn't happen every single time you reload your Apache.
?
Correct, I'll edit my post to better delineate.
If you use the </>
button for pre-formatted text, it'll align better.
He spoke English and we both speak English...
Yet we understood two different things!
Therefore we must be speaking two different (versions) of English! - LOGIC
He spoke English and we both speak English...
Yet we understood two different things!
Therefore we must be speaking two different (versions) of English! - LOGIC
Lol are we going to get into Wittgenstein's philosophy of language here?
OK so it is not (currently) a stale process problem.
Now we wait for another compliant.
If none come, then maybe "we fixed it" with the restarts and what-knots...
If they do come, then we can be pretty certain it is a client-side problem.
Although I haven't yet fully ruled out some weird "session resumption" server-side issue...
And perhaps PFS plays some part in this too.
You might need to wait until the certificate issue turns up again. If you stopped Apache, checked for any running process, started it again it cannot have used the older certificate in any way (unless you configured it somehow to do so, but I'm pretty sure that's not the case Also, I wouldn't know how to configure a single process to use the older certificate )
I.e., you might need to wait until the next renewal..
Got it, thank you for your help. I'll return to the thread if a new error occurs and if nothing new comes up, I'll close the thread and mark it as resolved. Thanks for your help!
Is this weirdness?
From my perspective...