Hello,
First of all sorry for my english, trying my best :]

The story is: I'm running a small webserver and to monitor the amount of
people going trough my pages, I've made a simple counter (storing the
data in a text file), no matter the details, the important thing is that
it WORKED just the way I wanted it to. Till yesterday evening.
Today I noticed that all of the counters, that were modyfied since
yesterday, have been blanked. I started looking trough the logs and
found a large amount of
PHP Warning: fread(): Length parameter must be greater than 0.
which was the expected behaviour when reading an empty file.
After a while of checking, I got to the fact that something's wrong with
the fwrite() function.
I've writen a 'test' script only to see if I can write files.
When writing to the /tmp dir, all went fine, but when I tried to write
to any of the other directories within my $WWWroot the result was an
empty file.
This is the script:

$data="some data";
$file="/wwwroot/file"
$handle=fopen($file,"w");
fwrite($handle,$data);
fflush($handle);
fclose($handle);

And as written above, the output was only an empty "" file /wwwroot/file
nothing more.
I thought about premissions, but after setting the wwwroot a+rwx,
setting the owner and group as the same as the apache server works under
I got the idea that's not it.
I reinstalled the apache and php.
Now I'm using httpd-2.1.9 and php-4.4.0 (as a module) but the problem is
still there, before I was using httpd-2.1.8, but as I said, the problem
appeared out of nowhere, when the server was just running on it's own,
without upgrades, patches, config changes, or anything other.
In fact all it was doing trough the night was serving the websites and
receiving mail.

I runned out of ideas. The logs don't show anything related to this. I
tried to enable all debug logging, but despite the fact that I'm
receiving now 3 times more info on everything else, there's nothing on
the fwrite() attempt or related.

Can anybody help?
If any more data is required on my side, I will gladly cooperate to get
the thing solved.
Hello again, some extra info on my case:
the fwrite is completely fine, when fopen is in 'a' mode!
Thus leading to a temporary workaround like this:

$file = "/wwwroot/file"
$countt = explode(".", fread(fopen($file,"r"), filesize($file)));
$count=$countt[1];
$count++;
$handle=fopen($file,"a");
ftruncate($handle, 1);
fwrite($handle,$file);
fclose($handle);

Now having a file with content in the form:
.15
makes it possible to use the above as a workaround..
but still I need to find out what's the problem here. The counter isn't
exactly the only thing I use fwrite for..

The clue I got is, non-empty files are ok to be written in (appended),
empty on the other hand, are totaly uncool for that.
So using a ftruncate($handle,0); is just as I'd use fopen($file,"w");
(gives the same result).
Hello again, here's some more extra info on my case that came out while
Suhas Pharkute was helping me find a resolution:
So the safe-mode is off, that's for sure, I turned it off at compile stage.

I delete the file after each run of the script, the folder where the
script is located has 777 permissions and the ownership is given to uid
1027 gid 1020, whereas these are the uid/gid set for apache to run with
(and it does!).
The script:

$data="some data";
$file="file.txt";
$handle = fopen($file,"w");
fwrite($handle,$data);
fflush($handle);
fclose($handle);
if (is_writable($file))
echo "Is writable<br>";
else
echo "Isn't writable<br>";

works when I run it as root, from the shell (php script.php),
but when it's run from the server, it doesn't.
I mean, the output _IS_ in _BOTH_ cases "Is writable"
but that doesn't change a thing, cause when executed from the apache, it
just creates an empty file without content.

The other thing I was supposed to check was stat($file); with
clearstatcache(); called beforehand. The output of this is:

device number: 777
inode number: 1142470
inode protection mode: 33188
number of links: 1
_userid_of_owner:_1027_
groupid of owner: 1020
device type, if inode device *: 0
_size_in_bytes:_0_
time of last access (Unix timestamp): 1132482491
time of last modification (Unix timestamp): 1132482505
time of last inode change (Unix timestamp): 1132482505
blocksize of filesystem IO *: 4096
_number_of_blocks_allocated:_0_

and of course when executed as root:

device number: 777
inode number: 1142470
inode protection mode: 33188
number of links: 1
_userid_of_owner:_0_
groupid of owner: 1020
device type, if inode device *: 0
_size_in_bytes:_9_
time of last access (Unix timestamp): 1132482980
time of last modification (Unix timestamp): 1132482980
time of last inode change (Unix timestamp): 1132482980
blocksize of filesystem IO *: 4096
_number_of_blocks_allocated:_8_


Can anybody help me?
I missed the beginning of this thread...
content is appended to it. Furthermore, IF there is content in the file
it can be appended to via web, but if it's an empty file it will not get
written too. Am I following correctly?

-Brian
--
s/:-[(/]/:-)/g


Brian GnuPG -> KeyID: 0x04A4F0DC | Key Server: pgp.mit.edu
======================================================================
gpg --keyserver pgp.mit.edu --recv-keys 04A4F0DC
Key Info: http://gfx-design.com/keys
Linux Registered User #339825 at http://counter.li.org
Yes, the shell command "php test.php" works fine when executed as root
(any other user has the same problem as from the web)
Exactly, as strange as it sounds, it's just like it is.

And another thing, the whole instalation was working perfectly for the
past month or two, and now (friday->saturday) suddenly the above symptom
have appeared.
No config changes, no updates or anything else I could relate was
happening on the server, and there is no info in the log files on this
behaviour, the is_writable says it is writable. The safe mode is disabled.

Hope this tells You something, and gives You an idea on how to solve this.
This almost sounds as your disk usage (or quota) is at 100%.

Curt.
This is not a disk usage as it works when script is run from terminal as su\
Suhas
--

Contact @
Suhas Pharkute.
***@g
root can break the 100% barrier, it usually can get around 110%.

***@took:/tmp> df -h /tmp
Filesystem Size Used Avail Capacity Mounted on
/dev/ad0s1e 248M 8.2M 220M 4% /tmp
***@took:/tmp> cat /dev/random > foobar

/tmp: write failed, filesystem is full
cat: stdout: No space left on device
***@took:/tmp> df -h /tmp
Filesystem Size Used Avail Capacity Mounted on
/dev/ad0s1e 248M 228M 8.0K 100% /tmp
***@took:/tmp> su
***@took:/tmp# cat /dev/random > foobar

/tmp: write failed, filesystem is full
cat: stdout: No space left on device
***@took:/tmp# df -h /tmp
Filesystem Size Used Avail Capacity Mounted on
/dev/ad0s1e 248M 248M -20M 109% /tmp



Curt.
thanks, never thought about that.

Suhas
--

Contact @
Suhas Pharkute.
***@gmail.com
208 830 8915 (C)
208 429 6943 (H)
What does 'df -h' say on your system?
--
s/:-[(/]/:-)/g


Brian GnuPG -> KeyID: 0x04A4F0DC | Key Server: pgp.mit.edu
======================================================================
gpg --keyserver pgp.mit.edu --recv-keys 04A4F0DC
Key Info: http://gfx-design.com/keys
Linux Registered User #339825 at http://counter.li.org
!!!
The simplest of all is the most unforseen..
Wow. that's it ;) I NEVER EVEN Imagined to check for that, in fact that
_IS_ the thing.
I feel so totaly stupid right now, I checked everything except this,
although I think the fwrite _SHOULD_ return false on this, and it should
print out an error saying that there's no space available..
The thing is that my system has a few partitions, one of them is the one
containing wwwroot. I never even once got a msg that the filesystem is
full, as most of my operations (recompiling etc.) were conducted on a
seperate partition. Now I see it and can take it all together, as there
is one script doing backup of the www sites, it does so every night, and
that was the thing that made it full.
BIG ENORMOUS Thanks for the help to all of You, and sorry for the
problem, I would never ever thought about this, until You suggested it.

a modification to the topic of this message,
"Simpler the You could've thought" ;]