hiho@ll

situation:
a directory with many files (usually php scripts)
the scripts are used the whole time
they get executed (most by command line php) and die a few seconds later
but the scripts can be executed at the same time, this means one script can run more than once at any time (using "ps" command you would see many php processes using the same .php script)

so i have files which are used very often the whole time

problem:
updating one ore more scripts

question:
Q1: how can i update the scripts without affecting the whole runtime environment (no failures, if not possible -> Q2)?
Q2: how can i update the scripts without affecting the whole runtime environment very much (minimum failures)?
Q3: i think the biggest problem i will have is this:
script1.php gets opened by php process and it beginns to read it
update process tries to open the file for writing (i think the update will be a simple cp -f)

Q3.1 can the cp command update the script if it is opened by the php process for reading?
Q3.2 in which situations will the cp -f command fail to update?

cp -f begins to write something in the file
so the php process will read a mixture of the old script and the new script, or it can't read until the end, cause cp -f didn't finish (e.g. its a big file) so php will do a parse error
so how can i be sure that the update will work (the copy command), and the running scripts don't get affected?
hmm, i could use "mv" command, which should be much faster, not?
do i have the same problem, a script can't get executed, cause it gets currently updated by the mv command?

result:
a fast working update prog to update many servers at one time which is fail-safe

I think a description of how unix/linux deal with this scenario is helpfull to answer your questions.

When a process opens a file for reading, the whole file goes to a buffer. The process continues to read from that buffer, not from the disk itself.

When a process opens a file for writing, the file is written in a buffer. When the process close the opened file, than it will be writen back to the disk.

If a process opens a file for reading and other opens the same file for writing, the process that is reading will not be affected by the writing process. As soon the writing process closes the file, all reading process started after that, will get the new content.

So, I think is safe to install new versions of php scripts "on the fly".

The above description is not valid for databases of any kind. It's good only for regular files.

sounds very goood!

thx marozsas

but:

Q1: what about big files? or to ask it differently, how much of a file gets buffered? so what happens if the file is very big (well, i don't have this problem, but just of interest)
Q2: this would mean it will work with rsync? so i don't need to do this all by myself?
or does rsync some (for my specific problem) crazy stuff, which makes a problem with my scenario?

thx!!!

The trick is to have the new version written to the disk (under different name eg new_<old_name>), then then use mv cmd (eg mv new_<old_name> <old_name> ) which just changes entry in inode table (ie dir file). Takes a fraction of a sec to change.
Always keep prev versions eg <old_name>_YYYYMMDD so you can back out broken scripts, using same trick.
Use rsync to move files between machines, but not for renaming part.

The buffer is in the disk too, not only ram memory. It uses the swap space. The files that are closed in the buffer are committed to filesystem by the sync command. All disk operation goes thru the buffer. The filesystem is very robust.
Even overwriting a real big file that takes forever to finish, the "previous" content will be available until the very last microsecond before the operation is committed.

None I can imagine.
Well, in fact, I can think in one.
I am supposing theses php are standalone. Or at least, if they work together, the API will not change. I mean, a change in the logic in one of theses scripts will not affect any other script which depends on.

Have faith in Linux, my brother

Cheers,