Nginx Server...:[emerg]: zero size shared memory zone "uploads"

[jezpi]

We Use head version of both scripts. the problem is that nginx ends its work with:
Nginx Server...:[emerg]: zero size shared memory zone "uploads"
error message
We solved that problem by adding following line to the main nginx config:
upload_progress uploads 1m;

Without definition of memory size nginx does not work

[szczym]

Me too head that bug with latest Barracuda switched to aegir0.4-beta1 on Ubuntu 10.04 at 720MB Linode (same as jezzjesz)

Omega8cc advised me to change aegir to HEAD - then, after clean reinstall of baracuda Nginx started to response but serves only picture "under construction" on main aegir domian (aegir login should be there) and 404 on url with string to log in as admin from email. It is 20 minutes since barracuda finished installation.

[omega8cc]

As discussed on the IRC #aegir at freenode: it should work with fresh install, however you have to wait for the first 2 cron runs, the verify task adds this to the config and restarts Nginx, since it first checks if you have compatible nginx version installed, provision has to run first to get the idea what is installed on the system and what config version for nginx should be used.

And the rest is Ubuntu specific. No idea why it is broken again, while Debian Lenny just works. I promise to try to debug it for Ubuntu next week. Of course I recommend to use Lenny.

[omega8cc]

This should be fixed now: http://community.aegirproject.org/node/216#comment-118

[zkrebs]

I had this issue today. After I upgraded Barracuda from A14 it seemed to work just fine. Then I installed my first Octopus instance and all of my sites that were on my main Barracuda install went down. Reason: nginx wouldn't start with "Nginx Server...:[emerg]: zero size shared memory zone "uploads".

The fix:
nano /var/aegir/config/nginx.conf

at end of #compression section I added:

upload_progress uploads 1m;

/etc/init.d/nginx start

Started up. just a heads up.

[omega8cc]

This is a known issue, but I was sure we introduced working upgrade path. No idea why it didn't work for you, sorry, we were unable to test all previous Barracuda versions to make sure it works as expected.

[jtbayly]

fresh install today on Ubuntu 10.04 using aegir 0.4-beta2 and I have this exact same problem. Just a heads up.

[omega8cc]

Don't use beta2, use HEAD.

[obrienmd]

Brand new barracuda install today on debian squeeze (our first on squeeze), had the same problem. Added upload_progress to /var/aegir/config/nginx.conf as shown above, and worked fine.

[omega8cc]

I can't reproduce it on any server, it just works for me - tested in 3 different datacenters, on Lenny, Squeeze, Lucid and Maverick - never experienced that issue again. (and I have seen this only on some old upgrade, never on install). So no idea why it doesn't work for you :/

There is different issue, however - forced initial Nginx restart doesn't work correctly for some reason. Working on it.

BTW: you promised something :)

[leevh]

Also had this problem from a fresh install (linode/lenny) a couple weeks ago. I fixed it using this solution and just finished running upgrade script for the rc2 aegir release and the problem popped up again. Easy fix though I suppose! :)

[omega8cc]

That sounds really weird. I tested it on many servers probably more than 100 times and never seen that. Are you forcing your hostname/IP or just running Barracuda with existing linode hostname?

[leevh]

I did it exactly as shown in the installer comments

_MY_OWNIP=192.168.0.108

_MY_HOSTN=server.mydomain.com

_MY_FRONT=aegir.mydomain.com

and replaced my IP and mydomain.

when I ran the update yesterday I, I only changed the email address and it detected my host/IP settings from before.

Sorry I'm pretty green with Linux so I'm not much help. Thanks for such an amazing script, I can really notice how fast my sites are on it!!

[mrfelton]

I just had the same problem on a 1.0-boa-T-8.7 setup. The only thing that I can think of that could have triggered this was a site delete operation failed. It failed, leaving me with no way to remove the platform from within Aegir, so I deleted the site note manually. After this, at a seeminly random point, nginx stopped and wouldnt start again reporting this error:/

Nginx Server...:[emerg]: zero size shared memory zone "uploads"

As mentioned several times above, adding upload_progress uploads 1m; to the nginx.conf file resolved the problem.

[ckleinschroth]

hello i've the same error in boa t8-9
if i add the line upload_progress uploads 1m in nginx.conf and now iv got another error:

the size 1048576 of shared memory zone "uploads" conflicts with already declared size 0 in /etc/nginx/conf.d/aegir.conf:143

any ideas?
thanks in advance

[omega8cc]

We no longer use this issue tracker. If you wish/need to continue any thread, please open an issue on d.o and reference there the original issue from github. Thanks.

[biomassives]

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a temporary error. The following address(es) deferred:

acmeideal@gmail.com
Domain biomassiv.es has exceeded the max emails per hour (118/100 (118%)) allowed. Message will be reattempted later

------- This is a copy of the message, including all the headers. ------
Received: from github-smtp2-ext1.iad.github.net ([192.30.252.192]:46218 helo=github-smtp2a-ext-cp1-prd.iad.github.net)
by server23.websitehostserver.net with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256)
(Exim 4.82)
(envelope-from noreply@github.com)
id 1WnRvl-002K7T-DH
for greg@biomassiv.es; Thu, 22 May 2014 07:17:53 -0500
Date: Thu, 22 May 2014 05:16:26 -0700
From: Barracuda Team notifications@github.com
Reply-To: omega8cc/boa reply@reply.github.com
To: omega8cc/boa boa@noreply.github.com
Message-ID: omega8cc/boa/issue/157/issue_event/123779241@github.com
In-Reply-To: omega8cc/boa/issues/157@github.com
References: omega8cc/boa/issues/157@github.com
Subject: Re: [boa] Nginx Server...:[emerg]: zero size shared memory zone
"uploads" (#157)
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="--==_mimepart_537dea9a45b10_6943fcfa117f2b8253031";
charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Recipient: biomassives
List-ID: omega8cc/boa <boa.omega8cc.github.com>
List-Archive: https://github.com/omega8cc/boa
List-Post: mailto:reply@reply.github.com
List-Unsubscribe: mailto:unsub+i-476041-474419843e9ae7d160bdd36b643aa46ddc626387-4379874@reply.github.com,
https://github.com/notifications/unsubscribe/4379874__eyJzY29wZSI6Ik5ld3NpZXM6TXV0ZSIsImV4cGlyZXMiOjE3MTYzODAxODYsImRhdGEiOnsiaWQiOjMyODUxNDE0fX0=--4bf6a186d4d66d9757191bd73e342dd25657aba0
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: greg@biomassiv.es
X-Spam-Status: No, score=-3.2
X-Spam-Score: -31
X-Spam-Bar: ---
X-Ham-Report: Spam detection software, running on the system "server23.websitehostserver.net", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
root@localhost for details.

Content preview: Closed #157. --- Reply to this email directly or view it on
GitHub: #157 (comment) Closed
#157. [...]

Content analysis details: (-3.2 points, 5.0 required)

pts rule name description

---

-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high
trust
[192.30.252.192 listed in list.dnswl.org]
0.0 HTML_MESSAGE BODY: HTML included in message
1.8 HTML_IMAGE_ONLY_08 BODY: HTML: images with 400-800 bytes of words
X-Spam-Flag: NO

----==_mimepart_537dea9a45b10_6943fcfa117f2b8253031
Content-Type: text/plain;
charset=UTF-8
Content-Transfer-Encoding: 7bit

Closed #157.

---

Reply to this email directly or view it on GitHub:
#157 (comment)
----==_mimepart_537dea9a45b10_6943fcfa117f2b8253031
Content-Type: text/html;
charset=UTF-8
Content-Transfer-Encoding: 7bit

Closed #157.

—
Reply to this email directly or view it on GitHub.

----==_mimepart_537dea9a45b10_6943fcfa117f2b8253031--