WEbsites goes down, but all services running

The website is on a VPS. The request simply times out as I try to visit the websites during the down periods.

But I still do not understand why you need postfix. It should have nothing to do with contact forms unless they have been poorly setup on the website. Are you using an account server-side to send out emails? I thought you said not.

I know you would really like to know what process is taking the server down - it is just that I think the problem has more to do with the website you are running (or Apache config) than something to do with Virtualmin - otherwise we would all be seeing this problem.

I don’t set up a lot of software on sites but I know many require you to log into the mail server instead of having their own mail scripts. Seems safer in the long run.

Just a wild suggestion, before you restart apache, try restarting php first.

1 Like

I struggle with this

and in fact it’s off topic the point of this thread is to workout why apache and/or php fails, we could take the point that these are wordpress sites (php) and not some other ‘professional’ mumbo jumbo software installation. You may find php relies on an mta to send, mail hence the requirement for an mta.
So do we know that both apache & ,if required, php are not being killed by the oom killer ?
If the web sites are, if required, running the correct version (and perhaps mode) of php, yes stuff may work in php fpm mode but not in php fcgi mode. so from this it would be good to know if the sites are php based or something else so php can be ruled out.

Completely unnecessary and far from being safer as it exposes the mail to the client which is about as good as a mailto: in any website an invitation to spam. A contact form which is client side should simply submit to server-side any data in the form.

But as it seems to be “off topic” I’ll leave it at that. I hope someone resolves this.

This is probably on the right track.

The errors in the the error log “Network is unreachable” indicates whatever is being proxied to isn’t responding. If it’s a PHP app, then it’d be PHP-FPM or the FCGId server that’s failing to respond in a timely manner.

Why it is failing to respond can have infinite answers, but probably one of a few common problems. Could be resource contention (memory, disk, whatever), which would maybe indicate database isn’t properly tuned for the workload/system. Note that a lot of folks have a tendency to just randomly start increasing limits (such as on number of PHP processes or size of database buffers), which can make things worse if it hits physical limits of the system.

So it is probably not Apache (it almost never is, serving web pages fast is a solved problem). It is probably an application problem, maybe database, maybe PHP tuning/configuration, maybe some ugly queries in your app that need table indexes or need to be rewritten to be more efficient.

Just guessing, but you need to look at that side of things. Poking at Apache isn’t going to solve it, because Apache isn’t the one misbehaving, I don’t think.

Postfix and saslauthd are irrelevant to web service, and it is not surprising to see attackers trying to get in.

Thanks for all the help and advice that has been given here. I am working hard at trying to solve the problems, and I just enabled the Fail2Ban log file and as I compare it with a different server I run with Virtualmin it looks completely different. All I can see in the Fail2Ban log is as follows:

Also, the jail seems to be empty, meaning that Fail2Ban doesn’t seem to really ban users who attempt logging in or using the mail server to often. At my other serve, the log looks normal and I can also see lots of IP addresses in the Fail2Ban jail.

So, might there be some other thing like this actually causing the problem, that IPs aren’t banned, and that the server simply cracks down by too many attempts? Anyone able to give any advice on how to solve those Fail2Ban errors seen in the first screenshot?

There was an issue raised a little while back. If your firewall gets restarted then fail2ban needs restarted. It also must start in the proper order.

I think the reload behavior can be fixed in /etc/firewalld/firewalld.conf

# FlushAllOnReload
# Flush all runtime rules on a reload. In previous releases some runtime
# configuration was retained during a reload, namely; interface to zone
# assignment, and direct rules. This was confusing to users. To get the old
# behavior set this to "no".
# Default: yes
FlushAllOnReload=yes

Please open new topics for new questions.

You can see where the chatGTP ends and your spam attempt begins. At least it is amusing.

Prove me wrong by going to the upper right of your dashboard and using the clipboard to copy your system info and then paste it here.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.