Hello, whenever I reboot the server, the Nginx webserver never seem to auto-start when the server boots up, and I have to manually start Nginx each time.
I’ve been experiencing this issue for a couple of months now, as I was ok with manually starting the service each time I reboot, but it gets old after some time.
I can confirm the same issue is happening across multiple of my servers, I was also able to reproduce it on a fresh VPS. OS Ubuntu 20.04 and 22.04
It’s not clear to me from that thread which problem you believe was going to be resolved (and by whom).
We definitely aren’t replacing the nginx package on Ubuntu, so there should be no expectation that we’d fix any issues with the systemd unit file. If there isn’t yet an upstream bug filed about it with the Ubuntu folks (or possibly Debian, I don’t know who is responsible for this particular change to the systemd unit file), that would be the next step to getting it fixed. I don’t understand the problem well enough to reproduce it or report it myself (my test Ubuntu systems are working fine, so I’d need to set one up in some way that causes the problem).
There was also a Virtualmin bug mentioned later in that thread related to nginx config files, which I believe has been fixed.
And, I’m not certain we know why OP is having the problem. Is nginx service enabled on boot? Check systemctl status nginx and post the result here.
Ah well as indicated in that topic there was a solution. However, recent upgrade (7.7.3) of Virtualmin still appear to not restart Nginx. So I am assuming that somewhere in 7.7 it is not restarting or checking Nginx is running.
OK the Dashboard does indicate an opportunity to restart it (that is great) but surely it should restart after a reboot?
I accept it might be some other package update that is breaking this process but the check is in Virtualmin that shows it has failed to spark Nginx into life. But a Big red warning message would be better as unless the dashboard is open with the “Server Status” panel open the fact Nginx did not restart is easily missed until some one else spots (and screams ) that all websites are offline.
Seems to be popular to run Nginx along with Apache so maybe they don’t autostart Nginx since it could possibly cause a port conflict? Packagers aren’t assuming an either/or situation?
Virtualmin does not start services on boot. systemd does.
And, Virtualmin does not restart services on failure. systemd does (assuming it is configured to do so). We’re not going to reimplement the init system.
If there is a problem with the systemd unit file Ubuntu is distrtibuting for the nginx package on some deployments, then it needs to be reported upstream to the Ubuntu folks. We can’t fix it, as it’s not our bug. If I understood it and could reproduce it, I would report it. But, I don’t understand it and my Ubuntu test systems don’t have this problem.
It isn’t that you can’t enable nginx to start on boot (which Virtualmin seemingly does correctly during install). It is that it does not actually start on some systems due to something about the state of the network (which I, again, do not understand).
Also, it should not be popular to run nginx along with Apache. That’s a deployment smell that indicates something is probably wrong. A waste of resources at the very least.
Sure, and I accept that. I just do not understand why this problem is happening on reboot. I don’t understand what is happening to systemd and where that preventing the Nginx restart.
However my point there was that Virtualmin as a Server Management Tool could be more helpful.
It does already inform me that Nginx has not restarted (In the Dashboard on the Server Status Panel - if open) But I think this is such a critical bit of information that it should be “shouting” at me After all it can tell me I should reboot after a package update, it knows the Nginx is not running, then why not that?
…and although systemd has the responsibility of restarting Nginx, Virtualmin certainly does have the ability otherwise how come that green arrow in the Server Status Panel resolve the issue?
Yes. I made the solution I ticked there which was on my v7.7 boxes but had the same problem on v7.7-3 following upgrade - I have not rechecked /lib/systemd/system/nginx.service as I was not anticipating an undo
Just checked and where did that go? the addition of that fix has gone! I have put it back - so wait for whatever replaced/edited the file to do it again.
Only files in /etc are protected against that. Most files in packages are not meant to be modified. If you want a custom one, you’d need to create one in the systemd directory in /etc. I don’t recall details, but modified files in /etc are left alone in the default dpkg configuration.
I am not aware of a Nginx update having taken place since the original install. Though there have been many other package updates. (as prompted). Normally I only update Nginx config inside Virtualmin (where I have it installed).
You said you changed the systemd unit file, right? That isn’t an nginx config file, that’s a package-provided system file. Config files live in /etc, and do not get replaced by package updates.
You can override the systemd unit file in lib/systemd by putting one somewhere in /etc (you’d want to check the docs for details, but there is an order of precedence in which systemd chooses which unit file is the right one…those in /etc have higher precedence than those in /lib), and files in /etc will not get replaced on package updates.
The only update that would have overwritten part of the nginx package would be an nginx package update. Files sort of belong to packages (except those in /etc as previously mentioned…and those in /var for different reasons) and they expect to be able to overwrite them without concern for the whims of humans.
) that all websites are offline.
) so as no Apache server there shouldn’t be a port conflict.