Nginx 11 Resource temporarily unavailable after smaba is started [reprinted]

Address: http://thobian.info /? P = 1367

The question may be a bit of a title. After all, we will talk about the 500 case that occurs only when nginx is in a special environment.

Let's talk about our development environment:

• Web server: nginx, built on a local Virtual Machine (the virtual machine is directly copied)
• Development Tool: Zend Studio (this is nothing to mention)
• Virtual Machine Operating System: centos 6.0
• Local Operating System: win7
• Local and virtual machines share files through Samba. Directly modify the code under Win and synchronize it to Linux

During code modification over the past few days, it is found that after each modification to CSS and JS files, the first access to these files will always produce a 500 error. This will not happen to PHP files. Although it was only the first access problem after the modification, the impact was not very great, but this strange problem was driven by my own obsessive-compulsive disorder to find out why.

The first thought was whether nginx had configured the response proxy and static File Cache (not long after nginx was accessed, and the server was directly copied from the virtual machine ), so I checked the nginx configuration and found that these functions were not enabled. It seems that this guess can pass.

Then I thought that since it is a 500 error, nginx will naturally generate the log and check whether the log is correct.

2014/05/04 14:43:38 [crit] 1774#0: *414 open() “/data/vhosts/domain.com/public_html/css/style.css” failed (11: Resource temporarily unavailable), client: 192.168.128.1, server: domain.com, request: “GET /css/style.css HTTP/1.1″, host: “domain.com”

Note that "resource temporarily unavailable" is unavailable for the moment. But isn't the file there? How can it be unusable !? There is no way to find Google. Some Google users have encountered the same problem, which is easy to solve.

In the official nginx Forum saw someone encountered the same problem: http://forum.nginx.org/read.php? 2,191155. The best reply:

I believe samba uses fcntl(F_SETLEASE) on linux (and this is what causes EAGAIN)

It's messy. How does it relate to Samba !? What's more, fcntl, f_setlease, and eagain don't understand.

Enter stockoverflow with disappointment: Submit. According to this title, the Samba server was used to ask a question. When I checked it, I found that this eldest brother had followed the post on the official nginx forum to ask a question. Someone will reply to the samba configuration file and add two items to solve the problem: oplocks = No and level2 oplocks = No. With the restart, the problem is solved. Amazing

It is easy to solve the problem. But calm down and think about it. There are still a series of questions: what do these two configuration items mean !? Although the problem has been solved, it is unknown why the problem is further resolved. In addition, if it is a samba problem, is it true that no matter what web server will have this problem, and then another Apache is installed, there will be no 500 error. So the problem is not that simple, but there must be some connection, but you cannot solve it by yourself. If you are interested, you can see this webpage: Bug 8974-kernel oplocks are broken when UID (File )! = UID (process)