I need some help trying to work out why CGI.pm (guessing at the module)
appears to unlink a temporary file just after opening it and before writing
some uploaded file content to it.
I use in a form which I POST to a modperl Apache server
(version 2.2.14) on Fedora 10.
Intermittently the perl script is unable to access the CGItemp file. Here's
what I have found:
A network/packet trace shows the correct transmission of the HTTP and file
each time.
A Data::Dumper of the CGI variable instance shows the form variable has been
set to a file handle like this
'config_file' => [
$VAR1->{'.tmpfiles'}{'*Fh::fh00013Smartmon_Initial_Config_Ex port.txt'}{'hndl'}
]
However when the program goes to access the temporary file eg
/usr/tmp/45632, it does not exist.
I started printing the httpd PID in the HTTP output and found that some of
the processes consistently failed and others would consistently work.
I ran an strace on each of the httpd processes (running with 5 children) and
found that the failing processes would unlink the CGItemp file just after
opening it - so this is why it is unavailable to the perl script later on. A
good processes would open the CGItemp file and then start writing to it.
Why does it get unlinked just after opening and before the uploaded content
can be written to it?
--
View this message in context: http://old.nabble.com/Intermittent-File-Upload-Failures---CG I-tmpfile-unlinked-tp28078476p28078476.html
Sent from the mod_perl - General mailing list archive at Nabble.com.
An open file handle is a link; when creating a file with open you actually =
have two links to the file - one for the directory's link to it, and one fo=
r the process's link to it.
Therefore unlinking the file from the file system simply reduces its link c=
ount to 1, and it will stay around, writable on disk but not in any directo=
ries, until it is closed, at which time it will automatically disappear. =20
This is great for temporary files because you can take care of the extra di=
rectory entry right up front, no cleanup special required beyond closing th=
e filehandle.
I don't believe that the problem you are having is that the file is unlinke=
d from the filesystem. That would not stop it from being writable. The pr=
oblem may be that the file is inappropriately closed later before its fseek=
'd back to the beginning to operate on the temp contents, thus causing it t=
o really disappear.
David
-----Original Message-----
From: mjurgens [mailto:mjurgens@edcint.co.nz]=20
Sent: Tuesday, March 30, 2010 12:08 AM
To: modperl@perl.apache.org
Subject: Intermittent File Upload Failures - CGI tmpfile unlinked
I need some help trying to work out why CGI.pm (guessing at the module)
appears to unlink a temporary file just after opening it and before writing
some uploaded file content to it.
I use in a form which I POST to a modperl Apache server
(version 2.2.14) on Fedora 10.
Intermittently the perl script is unable to access the CGItemp file. Here's
what I have found:
A network/packet trace shows the correct transmission of the HTTP and file
each time.
A Data::Dumper of the CGI variable instance shows the form variable has bee=
n
set to a file handle like this
'config_file' =3D> [
$VAR1->{'.tmpfiles'}{'*Fh::fh00013Smartmon_Initial_Config_Ex port.txt'}{'hnd=
l'}
]
However when the program goes to access the temporary file eg
/usr/tmp/45632, it does not exist.
I started printing the httpd PID in the HTTP output and found that some of
the processes consistently failed and others would consistently work.=20
I ran an strace on each of the httpd processes (running with 5 children) an=
d
found that the failing processes would unlink the CGItemp file just after
opening it - so this is why it is unavailable to the perl script later on. =
A
good processes would open the CGItemp file and then start writing to it.
Why does it get unlinked just after opening and before the uploaded content
can be written to it?
--=20
View this message in context: http://old.nabble.com/Intermittent-File-Uploa=
d-Failures---CGI-tmpfile-unlinked-tp28078476p28078476.html
Sent from the mod_perl - General mailing list archive at Nabble.com.
I am having similar problems, though I'm not sure about temp files etc.
I have cgi-bin files that have been running for 5 years through two
upgrades. I just upgraded my OS to CentOS; perl to 5.8xxx and installed
new Net::Telnet (WORKS FINE) ... and the new CGI cpan module -- runs --
but the buttons don't work when I press them and submit, it goes back to
the first instance of the cgi-bin -- running from FORMS (html call to
the cgi-bin) works fine -- just cannot use the buttons!?!
(Sorry for not being mores specific, I am out of the office)
Thanks
jf
You'll need to be more precise than this because I can't quite follow your
logic given that in a "good" process the strace shows the file being written
to, but in a "bad" process it shows it being unlinked instead of being
written to (and it is never written to, and the perl also can not find the
file after being given the file name).
Ihnen, David wrote:
>
> I don't believe that the problem you are having is that the file is
> unlinked from the filesystem. That would not stop it from being writable.
> The problem may be that the file is inappropriately closed later before
> its fseek'd back to the beginning to operate on the temp contents, thus
> causing it to really disappear.
>
> David
>
--
View this message in context: http://old.nabble.com/Intermittent-File-Upload-Failures---CG I-tmpfile-unlinked-tp28078476p28088874.html
Sent from the mod_perl - General mailing list archive at Nabble.com.
Let us say for the sake of example that this is the sequence during success=
:
1. create/open file
2. write to file
3. close file
4. reopen file
5. provide file handle
6. close file
7. unlink file
Lets imagine that something went wrong with the apache server and it droppe=
d the post/form data that otherwise would have been put in its temp file. =
The system sequence would look like this:
1. create/open file
3. close file
7. unlink file
Hm, that sounds like your symptom.
A close friend and business partner of mine was complaining about a problem=
he encountered in his apache server unexpectedly after years of problem fr=
ee operation.
His cgi scripts were randomly - and for certain clients consistently - not =
receiving their form posts. His error logs were spammed, his customers wer=
e quite annoyed.
We spent some time speculating about what could cause such behavior, but in=
the end he went for the generally sane step of making sure he had the late=
st apache server software running on his servers.
The problem disappeared.
It occurs to me that the symptom you are troubleshooting is remarkably simi=
lar to the same problem. Perhaps there is a bug that has been fixed, and y=
ou need to update apache to a newer release?
It is worth a try, and it does match the case study - though we have no ide=
a why the server would suddenly have developed this form data delivery prob=
lem. Perhaps its one of those strange artifacts in complex systems that we=
work around and don't worry about overly much.
You'll need to be more precise than this because I can't quite follow your
logic given that in a "good" process the strace shows the file being writte=
n
to, but in a "bad" process it shows it being unlinked instead of being
written to (and it is never written to, and the perl also can not find the
file after being given the file name).
Ihnen, David wrote:
>=20
> I don't believe that the problem you are having is that the file is
> unlinked from the filesystem. That would not stop it from being writable=
..=20
> The problem may be that the file is inappropriately closed later before
> its fseek'd back to the beginning to operate on the temp contents, thus
> causing it to really disappear.
>=20
> David
>=20
--=20
View this message in context: http://old.nabble.com/Intermittent-File-Uploa=
d-Failures---CGI-tmpfile-unlinked-tp28078476p28088874.html
Sent from the mod_perl - General mailing list archive at Nabble.com.