ERPNext nginx.conf breaks other nginx sites

Dear all,

I’m working to get ERPNext back up and running after a power outage. Never in a million years would I have dreamed it would be so difficult.

I’ve received a lot of help here --> Sorry! We will be back soon!

And managed to get ERPNext back up and running…well sort of.

The problem is, I can only get it to run if I put the nginx.conf file in sites-enabled (not conf.d) and when I do that it renders my other Nginx sites inaccessible.

I guess I need to change something in the nginx.conf file but have no idea what…

The odd thing is that everything (ERPNext and my other sites) were working flawlessly before my power outage. I don’t know what got corrupted but my other sites came back online without any issues whatsoever when the power came back up. ERPNext, on the other hand, has been quite a mess… :frowning:

Any advice available will be most appreciated.

To summarize:

I want ERPNext and several other web apps (Moodle, Limesurvey, etc.) to be served by Nginx.

Regards

Jason

1 Like

This is just a hunch, but it really sounds like something messed up your nginx.conf before the power outage. Then, when the power went out, nothing new was damaged perhaps, but the reboot forced a reload that activated your incorrect nginx conf files.

It’s hard to say what the problem is exactly, but it should be possible to figure out by examining the config files. It’s odd that things are behaving differently in conf.d vs sites-enabled. It sounds like an issue with default sites. When the frappe conf file is in conf.d, what happens when you try to access the url?

peterg,

Thanks. I’ve been messing with this so much my head is spinning.

Now, for some reason, it doesn’t matter where I put the ERPNext Nginx conf file. I had it working this morning when it was in sites-enabled but now if I put it there Nginx will not restart.

The odd thing is that I don’t think I changed anything. I simply realized that none of my other sites were running and suspected it was because of the conf file in Nginx so I removed it and restarted Nginx and sure enough the other sites all came back online (were accessible).

Now if I reverse the process and put it back Nginx won’t restart.

If I try to access after putting the conf file in conf.d I simply get a “cannot connect to the server” error in my browser…I guess because Nginx is not running and I am attempting to access ERPNext with a domain.

The reboot hypothesis is certainly possible but I had restarted Nginx a few times prior to the power outage so it seems a bit odd that it would be the case…or no?

Thanks, in advance, for any additional help and/or advice you can provide.

Regards
Jason

P.S. Looking at the Nginx log now and see the following error from when I just tried putting the conf file in conf.d again.

“/etc/nginx/conf.d/frappe-bench.conf” failed (2: No such file or directory) in /etc/nginx/nginx.conf:74

Something is goofed up with your link files and that is causing nginx to fail on load. Can you confirm that the file /etc/nginx/conf.d/frappe-bench.conf points to exists? What is the output of nginx -t?

peterg,

Thanks again. Let’s see… nginx -t gives me:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

Seems ok I guess.
Jason

P.S. I wonder if running “bench setup nginx” again will help…?
P.P.S. Never mind, I gave it a try but nothing changed. Nginx still refuses to start as soon as I create the symbolic link in conf.d :frowning:

One more P.S. --> I read somewhere that Nginx might fail to restart after adding the symbolic link. The information indicated that removing the default conf file would fix the problem. I tried that but unfortunately it didn’t work. :frowning:

peterg,

Ok, big sigh…I managed to get everything (ERPNext and my other apps) functioning.

I’m not really sure what was corrupted but…I ran through the process outlined in the last post here (Let's Encrypt setup problem "No site named..." error)

Then symlinked the nginx file that was reconfigured to my sites-enabled directory in Nginx and it restarted and is serving all my sites.

I’ll have to try and figure out what was wrong by sifting through the configuration that is now working…will do that later. I’m going to take a break now.

Thanks again for all of your help.

Cheers
Jason

P.S. Now I feel like crying…ERPNext is up and running but there is no login option…why? This is so weird. Why can’t I log in…?

Hmm…what happens if you go directly to your domain.com/login ?

peterg,

Thanks, that gets me in. In fact, I guess I had not logged out because I was able to login without even entering my details.

And, even better news, if I logout then everything appears normal with the login option etc.

So, fingers crossed, I think I’m back in business. :slight_smile:

Thanks again for leading me along the way. :slight_smile:

Cheers
Jason

@JLH As a rule of thumb you should always keep a snapshot of your working machine for disaster recovery especially since you run multiple sites on one machine. This would have saved you a ton of time if you had one before the last episode. when I had a similar issue I didn’t fret because it took me all of 10 minutes to get my machine and apps back up and running.

Just my thoughts.

Yeah, you’re definitely doing this the hard way. :slight_smile:

If you’re not very comfortable with nginx, supervisor, etc., docker simplifies the process dramatically.

flexy2ky, peterg,

Thanks, yes, definitely the hard way but, for now, it’s actually helping me to better understand the structure of ERPNext. It’s not mission critical, yet, so I can get away with the hard way. :slight_smile: I’ll definitely be working with a more stable, secure, and easily recovered instance once I get through the stage we are currently in with the demo.

Thanks again for all your support. :wink:

Jason

Glad to help, and manual is certainly a good way to learn.

There’s nothing magical about bench setup nginx. All it does is read your various site_config.json files, builds an nginx config file based on those values, then creates a symbolic link to your nginx/conf.d directory.

Nginx is very fussy about configuration files, so if it ever won’t start that’s your major clue. Either something is wrong in configuration settings, or the symbolic link isn’t working. Logs and test startups (via nginx -t) should pretty much always tell you exactly what the problem is.

2 Likes