Nginx: [emerg] invalid number of arguments in "include" directive in /etc/nginx/sites-enabled/


I’m deploying a site to staging for the first time and getting the error below when I run ansible-playbook server.yml -e env=stagin.

I tried getting verbose output ansible-playbook server.yml -e env=stagin -vvv and it doesn’t report the error at all much less with verbose output.

When I access the site I get the generic “Welcome to NGinx” message:

I even destroyed the server and reran. I don’t understand why this is happening and can’t find any details helpful to resolving the issue. Can anyone explain?

The only thing I can think is that I have the domain name mix-matched in my group_vars/staging/vault.yml and wordpress_sites.yml where at line 6 and 13 I list instead of (which is what the production URL is and I assume I’m not suppose to use that there but vaguely recall someone telling me I am even though there is no documentation or code comments that would advise me to do that from my recollection).

Thank you for your time!

I think you got unlucky :disappointed: and pulled a version of Trellis that existed with a flaw for less than 24 hours. I’m guessing you need the fix in

1 Like

Thank you for the reply. I applied that fix manually and re-ran on a new Droplet but now I’m just getting a 500 error.

Check your logs
Check your logs.
Check your logs.
Check your logs.
Check your logs.
Check your logs.

1 Like

@swalkinshaw I appreciate your time, but I don’t appreciate being treated like that. I always try to be respectful to you, and everyone here. If you don’t want to answer my questions because I’m annoying, that’s okay too. But please give me the same level of respect I show to you.

The logs (/var/log/nginx/error.log) don’t report anything useful. In context, @fullyint just noted that the original issue was the result of a missing semi colon in Trellis. I can’t think of any way I could have ever found that without dozens and dozens of hours of searching.

Now I’m getting a 500 error - which is inconsistent with what the docs say I should experience, and inconsistent with my last (and first) experience building a site using Trellis / Bedrock / Sage.

I’m happy and willing to debug. And I’ve paid, and offered to pay @fullyint for assistance with this and other issues. I’ve been referred here for the time being.

But literally every time I run a command I get a different error in every step of the process of working with this system. It’s unbelievably temperamental and I intend to contribute to the docs and code to help others through these issues. But only once I have successfully deployed a few sites without a barrage of errors. Until then, I’m going to continue to need a little assistance to get there.

Literally the only thing I’ve done is create my droplet and run the aforementioned ansible command. I can’t think of any reason why I should be getting a 500 error outside of the fact there is possibly something else wrong with the versions of Trellis / Bedrock that I have. This is the only place I know to go to get a confirmation about that.

Thank you for your time and for your help today and in the past.

Looks like you took that differently than I meant it. Only reason I even repeated that is because replies can’t be less than 20 characters :pensive:

Anyway, there is literally nothing we can do to help with the information you original supplied:

I applied that fix manually and re-ran on a new Droplet but now I’m just getting a 500 error.

Being respectful of our time and help means providing us with more information to help you. If you had already checked the logs, then it would have been useful to say that. Or even supply the log file contents regardless.

/var/log/nginx/error.log is not the place for site logs. They are in /srv/www/<site>/logs. So look at the error log there and let us know the contents so we can help.


I can see how you you might read @swalkinshaw’s comment as not nice. I guess the repetition was just a 20 characters thing, but I originally read it as a persistent reminder you’d get from a mentor who knows how tough it is to tenaciously scrutinize and take action on error output.

I originally clicked “like” on @swalkinshaw’s reminder to check the logs because a 500 error is typically an Nginx issue and likely reported in the Nginx logs. You reported only “now I’m just getting a 500 error” with no other info or indication of having tried to research the issue. The suggestion to check the logs is probably the most helpful advice anyone could give.

Errors are always an unwelcome interruption and disappointment. Error output often contains info that is unfamiliar and which is often unhelpful. It’s a pain to deal with. Still, “check the logs” is the right thing to do. @swalkinshaw’s response wasn’t dressed up, but having read probably 1000s of his rational interactions with people, I knew he meant no offense.

I’m sad you ran into the the original issue you reported. To share an example of taking action on an error message, when I searched the original issue of invalid number of arguments in * directive I quickly saw a several instances of people missing a semicolon in their Nginx conf. Your error message gave you a file and line number to check:

invalid number of arguments in "include" directive in /etc/nginx/sites-enabled/

It would be appropriate to inspect that file on the server, that line. I understand that Nginx confs may not be familiar, so you may not have noticed that a missing semicolon was a problem. In that case, you might post “I get an error specifying a file and line number, here is a copy of that file. Can anyone help me see the problem here?”

Preferably before even posting, you could check for recent action in the codebase for the related lines. Suppose you examine the line 50 indicated in your error message and see that it has include h5bp/location/cache-busting.conf. You could find the related file in Trellis and check for changes to that section, e.g., this line with note “add missing semicolon”. Such a technique won’t always yield such an obvious fix for the problem, but even if you’d searched the Trellis repo for a string from line 50, e.g., cache-busting.conf, you’d probably have found the discrepancy between your files and the latest upstream Trellis.

Ok, I get it that one might not know to take all those steps. And yes, it’s easy for me to lay them out in hindsight now that we know the problem was a missing semicolon. But I think I would have been justified to have originally responded “check the error message,” encouraging you to pay attention to line 50 of the indicated file. Such a response would have been guiding you on the next step to take, just as “check your logs” was the next step for a 500 error.

Ok, you’ve subsequently reported that /var/log/nginx/error.log didn’t show anything helpful. Searching discourse or the trellis codebase for error.log will reveal a site-specific log at /srv/www/ Hopefully that log will have something useful. But maybe not.

If this other log doesn’t show anything helpful, here are the next steps I’d take. If a playbook fails, it’s possible for the server to be left in a weird state. Try SSHing into the server as a sudoer (root, or the value of your admin_user)…

# restart php just to be sure
sudo service php7.1-fpm reload

# check nginx config -- should indicate all 'ok'
sudo nginx -t

# reload nginx or maybe `sudo service nginx start` if it says it's not running
sudo service nginx reload

Then rerun the server.yml and rerun deploy.yml playbooks just to make sure any missing pieces are provisioned and deployed.

If this site is multisite, you may get a 500 error unless you use wp-cli to install:


@swalkinshaw I’m glad to know you weren’t just venting on me. I thought it was out of character for you from what I’ve seen of you in the forums. I’m happy to apologize for misunderstanding you.

@fullyint, thanks too. I’m going to read through your message in full later though.

Thank you both for your time.

Or in other words, fullyint all like