Gitlab stop working after instal iRedMail - nginx

I have a little problem.
I have VPS with debian 8. I have installed on it apache2 serwer and gitlab ce with default settings.
My serwer work on port 80 and my gitlab worked on 81 ( external_url ).
Everything stop working when i installed iRedMail.
Now I have uninstalled iRedMail but gitlab doesn't work.
After use command "gitlab-ctl restart" all packages are ok (gitlab-workhouse, logrotate, nginx, postgresql, redis, sidekiq, unicorn), but If i try to open site with gitlab, I have got error the page timeout.
What and how should check to solve this problem?
I have to add that I hace checked listen ports and nginx are in this list.
tcp 0 0 0.0.0.0:81 0.0.0.0:* LISTEN 4534/nginx
---------- EDIT
"stop working" = after I type "external_url" (which worked) I got "Connection timed out".
I have checked logs in /var/log/gitlab for
gitlab-rails, gitlab-shell, gitlab-workhorse, nginx etc.
In gitlab-rails folder I found files : production.log (clear) and sidekiq.log. There are many of ERRORS ( I paste 2 first line, next are similar ):
2015-12-14_14:57:44.37657 2015-12-14T14:57:44.376Z 14796 TID-daijk ERROR: Error fetching message: No such file or directory - connect(2) for /var/opt/gitlab/redis/redis.socket
2015-12-14_14:57:44.37672 2015-12-14T14:57:44.376Z 14796 TID-daijk ERROR: /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/redis-3.2.1/lib/redis/connection/ruby.rb:180:in `connect_nonblock'
I Have to add that my apache server works fine on :80.

Related

Not showing pages of WordPress installed site on localhost

I have installed three WordPress sites on a WAMP localhost:
localhost/pacific_ocean
localhost/surfing_new
localhost/construction
Everything was working yesterday. Today, when I go to the above url's, the screen is blank white, and the WordPress installed site is not showing.
1.) I have checked options.php and it is pointing the site url is fine: http://localhost/pacific_ocean/
2.) I have run 'netstat -abno' on an administrator command prompt and it shows that [httpd.exe] is running on port 80
Then I ran httpd.exe -e warn and here's what I got:
(OS 10048)Only one usage of each socket address (protocol/network address/port) is normally permitted. : AH00072: make_sock: could not bind to address 0.0.0.0:80
AH00451: no listening sockets available, shutting down
AH00015: Unable to open logs
Is httpd.exe getting in the way of Apache running or is this another issue?
One of the sites shows /index of folders, but that's it.
Can someone help me?
Thanks!

What is the cause of the "502 Bad Gateway" after Ghost 1.8.7 update

I recently installed Ghost 1.8.4 and Nginx on my AWS ec2 Ubuntu 16.04 server. When I loaded my blog site, it correctly took me to the Ghost home page, from where I logged into Ghost admin. On the admin screen, there was a message to update.
I ran ghost update in putty
The update appeared to be successful, but when I returned to my blog site, I received the following error:
502 Bad Gateway
nginx/1.10.3 (Ubuntu)
Does anyone know a probably cause of this error and how to resolve?
I checked some posts, which suggested I should have turned Ghost off before the update. If this is true, is my ghost installation now corrupted?
I went to my ghost directory in /var/www/ghost and tried to run:
sudo service ghost start
but it returned:
Failed to start ghost.service: Unit ghost.service not found
and trying to stop, returns Unit ghost.service not loaded. Am I running the command from the correct location?
I've experienced 502 issues with ghost behind nginx several times over a few years of running it. I'm not sure if the cause of mine today is the same as yours, but what I observed was that after a restart ghost had changed its port number to one different than what its nginx config was listening on.
I followed these directions from https://web.archive.org/web/20200807095031/https://www.danwalker.com/running-ghost-on-a-5-digital-ocean-vps/ which resolved it for me:
See which port ghost is running on:
sudo netstat -plotn
Check that it matches the proxy_pass in the nginx config file in /etc/nginx/sites-enabled.
In my case the port in the nginx config had incremented to 2369 while the actual node process was running on 2368. Changing the proxy_pass port back to 2368 in my ghost blog's nginx config file resolved the issue for me.
I ran into the same problem after upgrading ghost.
Make sure the port number configured in your ghost's config file and the proxy_pass in your ghost site's nginx configuration files match.
Check the port number in
/var/www/ghost/config.production.json matches the proxy_pass port in the nginx config files.
/var/www/ghost/system/files/<yourDomainName>.<extension>.conf
/var/www/ghost/system/files/<yourDomainName>.<extension>-ssl.conf
In my case I had to change 2368 to 2369 in the nginx config files to fix the issue.
Make sure you restart your ghost and nginx after you make the changes.
# restart your ghost site
cd /var/www/ghost/
ghost restart
# restart nginx
sudo systemctl restart nginx
Hope this helps someone.
Apparently when I posted this issue it was due to a bug in the Ghost CLI that the ghost team were in the process of fixing.
They provided me with these instructions to run on my server:
systemctl stop ghost_www-blogwebsite-com
ghost update --force
The resulting output:
stopping Ghost [skipped]
Removing old Ghost versions [skipped]
This fixed the problem and updated to the correct version.

Gitlab ports 80 & 8080 taken by a separate Gitlab instance?

I have Gitlab 8.6 running on an Ubuntu 14.04 server that seems to have gotten messed up. I consistently get a 502 error when accessing the site. The server likely has not been restarted since installing Gitlab initially, and a power outage caused the server to reboot. Now, I cannot start/restart Gitlab due to what appears to be port conflicts.
I installed Gitlab via source, I don't have any custom port configurations, and am using NGINX. nginx -t shows that the configuration appears to be correct syntax-wise.
When I run netstat -tupln, I see that Unicorn & a Gitlab instance is already running on :8080 and :80 respectively at boot up. I suspect that a 2nd instance of Gitlab was installed which is being run at boot and that is causing the proper instance to have port conflicts when I try to run it via service gitlab restart. I'm not even sure if that's possible, but I can't seem to figure out where to go from here. Every time I run sudo gitlab-ctl reconfigure or service gitlab start, it fails and the unicorn.stderror.log shows bind errors to the :8080 port. I tried moving the Unicorn service to :8081 as well, but I still receive the port binding error.
Does anyone know how I can detect if there are multiple Gitlab instances running, and maybe if there is a way to remove a duplicated one if it's possible? Thank you!
EDIT: Here is what is in the /etc/gitlab/gitlab.rb file. Everything else is commented out.
## Url on which GitLab will be reachable
external_url 'http://my-gitlab-instance.domain.com'
EDIT 2: My /home/git/gitlab/ directory is mapped to https://gitlab.com/gitlab-org/gitlab-ce.git, and is on the 8-7-stable branch. gitlab-shell and gitlab-workhorse are on the correct versions according to https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/update/8.6-to-8.7.md
EDIT 3: I have gotten to a point where the Gitlab seems to self-check okay by removing the gitlab-ce package (https://gitlab.com/gitlab-org/omnibus-gitlab/issues/135), but the server returns a 404. NGINX, Unicorn, Sidekiq, and gitlab-workhorse all say that they're running. I see that unicorn.rb is listening on :8080, and nginx is listening on 0.0.0.0:80 and :::80. I guess now I'm troubleshooting this 404 and hopefully I will be back to my install-from-source.
What I have found is that there were 2 issues causing the errors I had.
First, I removed a "gitlab-ce" package that was installed, following the instructions here: https://gitlab.com/gitlab-org/omnibus-gitlab/issues/135. For some reason, when I restart the machine now I have to restart these services, in order, for Gitlab to run properly redis-server, gitlab, nginx. However, Gitlab does start responding properly after that.
Second, the 404 error was due to a different server that was also listening on that IP address, causing a conflict.
I will likely move to using the omnibus package on a fresh, new server going forward, but at least the immediate issues appear resolved. Thanks for your help, SLY!

HHVM not working with nginx

I try use HHVM with nginx in server CentOS 6.5 64bits but it's not working
hhvm --mode server -vServer.Type=fastcgi -vServer.Port=9000 -user nginx
Quote from HHVM's log:
Failed to initialize central HHBC repository: Failed to open /var/log/hhvm/.hhvm.hhbc: 14 - unable to open database file
Failed to open /var/www/.hhvm.hhbc: 14 - unable to open database file
Does someone know what to do in this situation ?
Two things here :
You're mentionning /var/log/hhvm/.hhvm.hhbc and /var/www/hhvm/.hhvm.hhbc .. is this a typo ? Can you give us the content of your server.hdf and config.hdf files ?
The folder /var/log/hhvm must be writeable by the account being used to run the webserver (ie nginx)
(On a side note, I guess it's --userand not -user)

vagrant puphpet nginx 502 bad gateway error

I have installed nginx via puphpet and i am using laravel 4.1 with centos6.4. Laravael needs php apc module which i have included on puphpet congig.yaml file. after i do a vagrant up and I go to my site I get: connect() to unix:/var/run/php5-fpm.sock failed (111: Connection refused) while connecting to upstream error. I changed my nginx $fastcgi_pass = "/var/run/php5-fpm.sock" which didn't work. Then i did vagrant ssh and I ran service php-fpm restart after that it works. But I don't want to configure anything after i run vagrant up thats the purpose of puppet. Now my question is any way i can restart php-fpm when i do vagrant up or any other way to solve php apc problem. thanks in advance.
solution: after hours of researching i am able to solve the problem. I added this code:
exec { "restart php-fpm":
command => "service php-fpm restart"
}
in mainfeast.pp at the end of the php-fpm class. for me the line number is 485 or after the service.
I'd much rather you submit an issue via github # https://github.com/puphpet/puphpet/issues
That said, you can run any arbitrary code on $ vagrant up and $ vagrant provision via the exec-once and exec-always features mentioned on the frontpage.
That also said, this is a bug I'd love to fix, please submit a ticket!

Resources