I have set up a cron to call a php script to run some download tasks at a regular interval.
The website is hosted at Bluehost. I have followed the instructions on how to set up a cron and that basically works fine, but the behaviour is different from when calling the script manually which i suspect has to do with directory settings. When using the cron i get errors:
Warning: copy(wp-content/uploads/feeds/full/1.csv): failed to open stream: No such file or directory in /home1/user1/public_html/import/custom-downloader.php on line 86
my php code is copy( $row["externalURL"] , 'wp-content/uploads/feeds/full/'. $localfilename );
I have also tried below with same result.
copy( $row["externalURL"] , $_SERVER['DOCUMENT_ROOT'].'wp-content/uploads/feeds/full/'. $localfilename );
I think think that i need to construct the path to /home1/user1/public_html/import/wp-content/uploads/feeds/full/ but i don't see how to do that.
First thing's first, make sure that 1.csv exists and that it can be read (there's read permissions on the file)
Second thing, double check if 'wp-content/uploads/feeds/full/1.csv' really is what you want to copy. Your error message indicates that the php script calling the copy method is /home1/user1/public_html/import/custom-downloader.php. However, the path you specified is relative. So your PHP script (barring any changes to the PATH to look for other directories) will look for /home1/user1/public_html/import/wp-content/uploads/feeds/full/1.csv -- which may not be what you intended!
This can be solved by using an absolute path to your wp-content folder, or by moving this script to the parent directory of wp-content.
Related
I have the following code:
rename ('/original_dir/file','/new_dir/file');
When the code is run, I get the following message:
Warning: rename(/original_dir/file,/new_dir/file): Operation not permitted
The file is however copied to /newdir, but is not removed from /original_dir
I am using rename to have it moved, not copied.
Both /original_dir and /new_dir have permissions set to 0777
This should work. Any ideas?
Rename is actually moving file with another name. As you can see from error, that operation is not permitted because, even though you have permission to write to file, you cannot delete the file if you are not owner of it on many Linux distributions. That's why your web server process is copying file, and not able to delete the old one.
Have you tried a copy() and a unlink()?
It may give you a better look at what goes wrong.
if( copy('/original_dir/file', '/new_dir/file') ) {
unlink('/original_dir/file');
}
source
Edits: if the script is being called from the command line, does it work with sudo? If it is being called from a webpage, does it work if you change the owner of the file to apache? Did you get the exact error code and check it in man 2 rename per this comment?
Basically it's this
>php /full/path/to/php/file.php
Fails with no output, warning, error anywhere in any log. Seems like it runs fine, but it actually does not run. However, changing working directory to /full/path/to/file/php
> php file.php
Works as expected.
What is special about this php script is that it:
reads files from an NFS mount
parses contents
loads file contents into a local MySQL table
renames files it has successfully loaded.
Operating system is CentOS 6.
Based on your edit, in your script, you should change to the correct directory. You can do that using using chdir:
chdir('/full/path/to/php/');
Now php is probably looking for the symlink in the wrong place.
You can use getcwd() to see in which directory you are.
$file=file('DATA.txt');
I keep getting "failed to open stream. No such file or directory in ...". This works when I run it on a server and browser. But the error occurs when I run the script using command line.
First of all take a deep breath and a tea ;)
The news is: DATA.txt is only a file-name.
A file normally is placed in a directory. As stupid as this sounds, well, as stupid this is: What is the directory?
The answer: the current working directory. This differs between servers and CLI.
So better add your directory as well:
$name = 'DATA.txt';
$dir = 'C:/';
$path = $dir.$name;
$file = file($path);
Hope this is helpful.
The question definitely lacks some clarifications, but two guesses:
Since you haven't provided a path, the file is expected to be located in the current dir, but server most likely runs as a different user (web, for example), and expects this file to be located in this user home dir (or current dir, to be precise).
Permissions, as usual.
I found that this works: $fname=str_replace(basename(__FILE__),'',__FILE__).'DATA3.txt';
I couldn't simply use "dirname" because I wanted this to work in both Windows and Linux (\ or /).
I am getting the following error from Apache
[Sat Mar 19 23:10:50 2011] [warn] mod_fcgid: stderr: PHP Fatal error: require_once() [function.require]: Failed opening required '/common/configs/config_templates.inc.php' (include_path='.:/usr/share/pear:/usr/share/php') in /home/viapics1/public_html/common/configs/config.inc.php on line 158
I am definately not an expert of Apache but the file config.inc.php & config_templates.inc.php are there. I also tried navigating to a test.html page I placed in common/configs/ so I assume there is no rights issues going on. I also set the rights on config_templates.inc.php to give everyone read, write, and execute rights. Not sure what to do at this point, I checked to see if there was a /usr/share/php directory and I found there was not but when I did yum install php it said it had the latest. Ideas?
It's not actually an Apache related question. Nor even a PHP related one.
To understand this error you have to distinguish a path on the virtual server from a path in the filesystem.
require operator works with files. But a path like this
/common/configs/config_templates.inc.php
only exists on the virtual HTTP server, while there is no such path in the filesystem. The correct filesystem path would be
/home/viapics1/public_html/common/configs/config_templates.inc.php
where
/home/viapics1/public_html
part is called the Document root and it connects the virtual world with the real one. Luckily, web-servers usually have the document root in a configuration variable that they share with PHP. So if you change your code to something like this
require_once $_SERVER['DOCUMENT_ROOT'].'/common/configs/config_templates.inc.php';
it will work from any file placed in any directory!
Update: eventually I wrote an article that explains the difference between relative and absolute paths, in the file system and on the web server, which explains the matter in detail, and contains some practical solutions. Like, such a handy variable doesn't exist when you run your script from a command line. In this case a technique called "a single entry point" is to the rescue. You may refer to the article above for the details as well.
If you have SELinux running, you might have to grant httpd permission to read from /home dir using:
sudo setsebool httpd_read_user_content=1
Run php -f /common/configs/config_templates.inc.php to verify the validity of the PHP syntax in the file.
You could fix it with the PHP constant __DIR__
require_once __DIR__ . '/common/configs/config_templates.inc.php';
It is the directory of the file. If used inside an include, the directory of
the included file is returned. This is equivalent to
dirname __FILE__ . This directory name does not have a trailing slash
unless it is the root directory. 1
Just in case this helps anybody else out there, I stumbled on an obscure case for this error triggering last night. Specifically, I was using the require_once method and specifying only a filename and no path, since the file being required was present in the same directory.
I started to get the 'Failed opening required file' error at one point. After tearing my hair out for a while, I finally noticed a PHP Warning message immediately above the fatal error output, indicating 'failed to open stream: Permission denied', but more importantly, informing me of the path to the file it was trying to open. I then twigged to the fact I had created a copy of the file (with ownership not accessible to Apache) elsewhere that happened to also be in the PHP 'include' search path, and ahead of the folder where I wanted it to be picked up. D'oh!
you can set the include path in php.ini
include_path = ".:/home/viapics1/public_html"
I was having the exact same issue, I triple checked the include paths, I also checked that pear was installed and everything looked OK and I was still getting the errors, after a few hours of going crazy looking at this I realized that in my script had this:
include_once "../Mail.php";
instead of:
include_once ("../Mail.php");
Yup, the stupid parenthesis was missing, but there was no generated error on this line of my script which was odd to me
The file was created by apache using mkdir() and fopen() etc..
How do i let my php CLI program be allowed to read that file that apache (that is what it says the user is) created so i dont get this error:
Warning: file_get_contents(./sessions/nl2larsjl6n3315mesghmspts7.txt): failed to open stream: No such file or directory in /var/www/html/cli.php on line 58
in the cli this my code for getting the file:
$alert = file_get_contents('./sessions/'.$sessionID.'.txt');
Short answer:
when you create it, you should run chmod(0777) on it.
Long answer:
chmod(0777) means "world readable and writable, and not actually recommended. Checkout http://en.wikipedia.org/wiki/Filesystem_permissions, http://www.linuxforums.org/articles/file-permissions_94.html for a complete explanation on these numbers.
Basically if you need it to be writable by a user, and readable by any user, do a chmod(0644)
EDit: i was quick to wrinte an answer... without reading the question carefully.
You seem to try and open the file from a different directory than the folder where you created it.
Try and see the result on echo getpwd() in the CLI script and then in the script running under www. I bet you will see different locations.
When executing CLI scripts you should either do a chdir() before running the command or use absolute paths at all times for the files you access.
I personally prefer the chdir() method.