We have a digital ocean server which runs 5-6 wordpress websites we have. We have 3 programmers who have access to the server. And today all websites were down until I fixed. I didn't know this issue until one programmer told me.
I checked the log and found out:
unix:/run/php/php7.0-fpm.sock failed
I saw this
Failed to restart php7.0-fpm.service: Unit php7.0-fpm.service is masked.
When I tried to restart it.
I checked the file and nothing was in that directory, so I install, then restarted the server, websites were back online.
My question is: is there any way to find out who did this? Or when it happened? Any helps will be appreciated. Thanks.
It sounds to me like nginx crashed and had to be restarted.
It's something that happens every now and again on our servers and restarting the server always gets it back online.
In this case, I don't believe that you should point the finger at anyone as sometimes these things just happen with servers.
It might be worth checking over the server for any potential issues like the disk space, etc.
Keep an eye on the error log and see if that provides any clues.
Related
I have a dynamic website developed by native PHP on a server using NGINX which was functioning normally, but suddenly it broke down such that the PHP files no longer run and just download automatically to the client with the code whole source when he tries to excute that files. I don't know why it happened, and is it because of a hacking or an internal server problem. When I contact the web host, he says that a php file that is causing this problem, knowing that I haven't changed anything at last time.
Please clarify the cause of this problem if you have an idea !! Thank you in advance.
There is no idea yet ? I add that the last time, the host re-initialized the configuration of the VPS, and the website is now running well. It is clear that the problem was in the configuration! But I ask the same question, why did this failure happen? I want to know the reason: if the problem comes from PHP files or from the server itself !!
Just back from six months away with work, wireframe in hand, ready to try my hand at programming again, only to be met with 'Forbidden you don't have permission to access localhost/~username/Sites from this server' when trying to open a textwrangler .php file in safari.
It worked a few weeks before I left, but now even those projects refuse to open. I've spent my first weekend off googling like a mad 'un, trying all the solutions without success. 10 hours over two days and nothing.
So I'm hoping those with more knowledge than I can think of what could have gone belly up. Localhost by itself returns the 'It Works!' message. I have run Apache configtest; it stated something but I've resolved that. Now it returns syntax OK. The httpd file has allow where it should be. And I've checked that I'm a user in the users list and that there is a config file with the same name. Added localhost after ServerName in the httpd file. Restarted Apache but that also failed.
Nothing has been updated or changed in respect to OS or browser. I installed the arduino software at Christmas, I can't see that don't anything but it may mean something to you. I don't get how it can now not work when nothing has changed? I'm running Mavericks and it's Apache 2.2. I am stumped, and I'm hoping someone may have a clue. The guys at Apple's store said they couldn't help because it's not their software.
If you could answer in baby steps it would be greatly appreciated as I thought I knew computers until I started opening the terminal and doing all this.
Thank you very much for your time and advice,
Keep well
EDIT: console log displays - client denied by server configuration: /Users/myUserName/Sites
I have been running a PHP site for years on my own servers. I recently purchased a dedicated server package and am trying to move my site to the dedicated server. I recently upgraded to PHP 5, and my current server is running PHP 5.6.16. I moved the files and the database, and put it in a live test domain, but the site is not functioning properly on the new dedicated server. Several key scripts are non-functional. I made sure that the dedicated server is running a version of 5.6. I have configured it to the same settings I have on the old server. I can see that the site is talking to the MySQL database. I turned on error reporting and I see no significant errors suggesting why these important scripts are now non-functional. I made sure the include path is there, and if it wasn't nothing would work. What am I overlooking? What could be different between one server and the other that might impact PHP functionality? I'm basically at my wits end here, so if these seems stupid please forgive me, but I don't know where to look next.
Start with the basics.
Does your web server respond to static page requests?
Is your web server configured to use PHP?
Can your web server execute and/or connect to PHP?
If you have a simple script with <?php phpinfo(); in it, does it work?
Are all the expected modules there in your phpinfo() output?
Do you have rewrite rules that need to be reconfigured? (Check your web server error log. Check your response status codes.)
Assuming PHP is all good, move into your application.
Are you absolutely sure error logging is on? (Again, check phpinfo() output. Try to force an error, maybe a syntax error or something and see if you see the error.)
How do you know your application is connecting to MySQL?
Start with a basic script that just echos some things.
Comment out large swaths of code and see if you can narrow down the problem that way, re-enabling chunks as you go. (You want to bi-sect the problem, cutting in half and in half and in half until you figure out exactly what the issue is.)
Other system-level things to check...
File system permissions? (See also https://serverfault.com/questions/48587/is-there-a-linux-log-for-when-a-user-is-denied-access-to-files-due-to-permission, for Linux.)
Firewalls? (Are you sure you can actually access MySQL over the network?)
Disk? (Are you out of space? Are your partitions set up correct? Is /tmp full?)
Once you figure out the problem, some advice:
Do this sort of thing regularly. Write a provisioning script to build yourself a new machine from one command, and do it regularly. These days with cloud providers (physical hardware or not) there's no reason you can't blow away your application servers on a regular basis, and re-provision them. Consider making this your system upgrade strategy. (Why reboot to get a new kernel when you can just have a whole new server with the new kernel and other patches, that you can cut over to?)
Ensure your development environment closely matches your production environment. (Consider Vagrant for this.)
You're using version control, right? If not, start using version control so that you can hack on your code for things like this and easily roll back when done.
Today, after working for ages, my mailing stopped working.
Zend Framework returned an error
Message: Could not read from localhost
After searching on the web, I relaised it came from Dovecot, on my Debian machine.
Looking at the logs, it said:
server1 postfix/smtpd[15194]: fatal: no SASL authentication mechanisms
And I couldn't find what was working wrong.
After some unlucky try, I decided to restart dovecot, which said:
Restarting IMAP/POP3 mail server: dovecotLast died with error
(see error log for more information): Time just moved backwards by 899 seconds.
This might cause a lot of problems, so I'll just kill myself now.
http://wiki.dovecot.org/TimeMovedBackwards
Which made me realise that I installed ntp because I had some problem with time synchronisation and it got the time back from more than 10 mn, which seem to give a hard time to dovecot.
So if that happen to someone, don't look for way to fix a SASL authentication, just try to restart your dovecot.
Since there is not once a mention of this problem I could find on the web, I hope this one will help people.
I have two servers, one production and one development. Both machines are windows machines, running Apache as the same user on the network. Last week, the network password for the user was changed, and that's when things stopped working.
Ok, no problem, once I identified that happened, I simply change the user/password credentials on the service, and restart Apache.
PHP doesn't want to open any files, or even acknowledge that they exist on the production machine. But everything is dandy on the dev machine.
For illustrative purposes, The following works fine on the development server, but not the production server:
<HTML>
<?php
$filename = '\\\\petra\\operations\\test.txt';
if (file_exists($filename)) {
echo "The file <u>$filename</u> exists";
} else {
echo "The file <u>$filename</u> does <b>not</b> exist";
}
?>
</HTML>
On the dev machine, I get a lovely The file \\petra\operations\test.txt exists but on my production machine, i get much less happy The file \\petra\operations\test.txt does not exist I can point to any file on any server on the network and the same will happen.
The hardware is completely different on the two machines, but they are very similar, software wise. For example the Apache configurations and php.ini files are exact copies.
This is related to a previous question I asked. At the time, I was thinking it was a bad file path, or maybe something someone else had made a mess of. That much was true (vis-a-vis, the password changed), but now both machines know the new user credentials and apache has been restarted on both.
Ideas? What would prevent PHP from being able to open a file?
EDIT: I don't think it has to do with user permissions on the files, just as such. Both machines are running Apache as the same user, pointing to the same file on the same network.
I did setup a new test file location on some other random machine on the network, upon which I then set very permissive permissions. my php now calls this: $filename = '\\\\procl35\\folder\\test.txt'; and I get The file \\procl35\folder\test.txt does not exist on the production server.
I have a resolution to this.
First, I should mention the production server is run by the IT department, in the server farm. In the original question above, I stated "I simply change the user/password credentials on the service, and restart Apache." Actually, IT changed the password and restarted Apache. This is a semantic difference, but one which turns out to be important here.
This morning, I asked the people over in IT if they had any ideas on the problem. The sysadmin poked around, and realized he hadn't actually changed the user password at all, despite his insistence that he had done so.
I'm not going to throw IT under the bus here. They're busy people, and they are human, and that's okay. But I will offer this resolution to future developers: If you encounter this kind of problem I suggest "re-updating" the password, because maybe it didn't happen right the first time. Maybe he updated the password on a different service (which also needed it anyway). Maybe he typed it in, mistyped one character, didn't read the failure message, and closed the window. Whatever, it's not important.
The resolution is to update the password in the service.
Cheers!