H
Hal Vaughan
A good while back I searched Google and posted in a number of forums about a
problem I had with Perl. I am (and was) using 2 computers, both running
MEPIS Linux, which is Debian based, so this problem might happen with
Debian or other distros as well. On my workstation, I was using Kate,
which is a text editor with a console in the bottom of the window. Kate
was on the workstation, but in the console, I connect to my server, the
system I'm programming on, with ssh. That means I am actually editing the
Perl file on one computer (my workstation), by reading and writing through
an NFS mounted directory, and I am running it on another (my server).
The first problem I had was that when I saved my script through NFS, then
tried to run it, I always got this error message:
/usr/bin/perl: bad interpreter: Text file busy
It would last up to about 10 seconds, after which I could run the file. I
searched newsgroups on Usenet and mailing lists and general Google searches
for a problem like this. (After all, why use something like Perl if I had
to wait to run a program as if I were compiling?) I found a number of
other people had similar problems, and in some groups the given solution
was simply to wait 24 hours for NFS to make the file available to all.
Since I found no answer, I got used to waiting 10 seconds to run a script
(and be thankful I didn't have to wait 24 hours!).
Then, the other night, when I was exhausted, my eyes were blurry and I
literally almost could not focus on my monitor, I noticed another problem.
I was so exhausted I thought I was not paying attention or just missed
something, but this was a problem I had suspected before. Even though I
could barely stay awake, I forced myself to track what was going on and be
sure I wasn't imaging things. I was finally able to prove MY CHANGES IN MY
SCRIPTS DIDN'T ALWAYS SHOW UP WHEN I SAVED! The worksation would see
changes, but when I ran the program on the server, nothing was changed. I
finally would add an extra print statement to see what was going on -- and
change NOTHING else -- and not only did the program start printing out the
extra data, but it started working like it should with my change in it.
Now it is important to note these changes were in Perl modules. When I
tried to run a just edited Perl program, I'd get the "text file busy" error
I mentioned above. If the program used a module, and the module was just
edited, I would not get that error, so I could edit a module on the
workstation, save it to the NFS mount, run a program on the server that
used that module, and it would run.
However, sometimes the changes would not appear on the server when I ran it.
I finally figured out that the changes might be cached somewhere or not
synchronized yet. I don't if adding the 2nd change and saving again forced
a buffer to be written out, or if the changes in the modules were not
getting to the server for that same pesky 10 seconds it took for me to stop
getting the "text file busy" error, but the changes in the program did not
show up when first saved, and did later.
At this point I felt like I had gone down the rabbit hole and my LAN was
going to have to be renamed Wonderland, things seemed so strange. I
*thought* the problem was NFS, but wasn't even sure, at that point, what
terms to use in searching. With the kind help of some people in the
Libranet-OT group at Yahoo (not a Libranet group -- the Libranet OT group
is made up of people that got tired of the Libranet support list being
censored and left Libranet's list and the distro but wanted to continue
their discussions) and some people on the Debian Users list (through
debian.org), I got some tips, found out I was missing the program exportfs,
posted that info, and finally the saving grace, one short message that
included a one line answer:
install nfs-kernel-server.
In Debian, that means running:
apt-get install nfs-kernel-server
as root. I did, and got errors as it tried to configure my /etc/exports
file. I had to edit my exports file a few times to make sure it worked.
It turned out my problem was only extra spaces. I won't go into the format
of this file, since that's posted in many other areas. I will say that my
options for each system were (rw,sync).
I don't know the name of the nfs-kernel-server package for RPM systems, but
basically, by making sure I had the rw,sync options set for each system
in /etc/exports, making sure the file was formatted properly, installing
this package, and, afterwards, running:
exportfs -ra
(which was probably already run when apt-get installed the package), I
found the frustrating "text file busy" error was gone.
Since I've seen this error in many posts, but never found an answer to it, I
thought I'd post this where I've asked for help, so others can find it via
Google and such in the future. I'm not an expert on NFS, and I really
don't know any other things to do to work with this problem other than what
I've posted. This is what fixed it for me. No more "text file busy"
errors, and no more Wonderland behavior of not updating saved files. If
you're having the same problem, I hope this fixes it . If it doesn't, I
really can't tell you what to try next, but I figure this info alone will
help a good number of people.
Hal
problem I had with Perl. I am (and was) using 2 computers, both running
MEPIS Linux, which is Debian based, so this problem might happen with
Debian or other distros as well. On my workstation, I was using Kate,
which is a text editor with a console in the bottom of the window. Kate
was on the workstation, but in the console, I connect to my server, the
system I'm programming on, with ssh. That means I am actually editing the
Perl file on one computer (my workstation), by reading and writing through
an NFS mounted directory, and I am running it on another (my server).
The first problem I had was that when I saved my script through NFS, then
tried to run it, I always got this error message:
/usr/bin/perl: bad interpreter: Text file busy
It would last up to about 10 seconds, after which I could run the file. I
searched newsgroups on Usenet and mailing lists and general Google searches
for a problem like this. (After all, why use something like Perl if I had
to wait to run a program as if I were compiling?) I found a number of
other people had similar problems, and in some groups the given solution
was simply to wait 24 hours for NFS to make the file available to all.
Since I found no answer, I got used to waiting 10 seconds to run a script
(and be thankful I didn't have to wait 24 hours!).
Then, the other night, when I was exhausted, my eyes were blurry and I
literally almost could not focus on my monitor, I noticed another problem.
I was so exhausted I thought I was not paying attention or just missed
something, but this was a problem I had suspected before. Even though I
could barely stay awake, I forced myself to track what was going on and be
sure I wasn't imaging things. I was finally able to prove MY CHANGES IN MY
SCRIPTS DIDN'T ALWAYS SHOW UP WHEN I SAVED! The worksation would see
changes, but when I ran the program on the server, nothing was changed. I
finally would add an extra print statement to see what was going on -- and
change NOTHING else -- and not only did the program start printing out the
extra data, but it started working like it should with my change in it.
Now it is important to note these changes were in Perl modules. When I
tried to run a just edited Perl program, I'd get the "text file busy" error
I mentioned above. If the program used a module, and the module was just
edited, I would not get that error, so I could edit a module on the
workstation, save it to the NFS mount, run a program on the server that
used that module, and it would run.
However, sometimes the changes would not appear on the server when I ran it.
I finally figured out that the changes might be cached somewhere or not
synchronized yet. I don't if adding the 2nd change and saving again forced
a buffer to be written out, or if the changes in the modules were not
getting to the server for that same pesky 10 seconds it took for me to stop
getting the "text file busy" error, but the changes in the program did not
show up when first saved, and did later.
At this point I felt like I had gone down the rabbit hole and my LAN was
going to have to be renamed Wonderland, things seemed so strange. I
*thought* the problem was NFS, but wasn't even sure, at that point, what
terms to use in searching. With the kind help of some people in the
Libranet-OT group at Yahoo (not a Libranet group -- the Libranet OT group
is made up of people that got tired of the Libranet support list being
censored and left Libranet's list and the distro but wanted to continue
their discussions) and some people on the Debian Users list (through
debian.org), I got some tips, found out I was missing the program exportfs,
posted that info, and finally the saving grace, one short message that
included a one line answer:
install nfs-kernel-server.
In Debian, that means running:
apt-get install nfs-kernel-server
as root. I did, and got errors as it tried to configure my /etc/exports
file. I had to edit my exports file a few times to make sure it worked.
It turned out my problem was only extra spaces. I won't go into the format
of this file, since that's posted in many other areas. I will say that my
options for each system were (rw,sync).
I don't know the name of the nfs-kernel-server package for RPM systems, but
basically, by making sure I had the rw,sync options set for each system
in /etc/exports, making sure the file was formatted properly, installing
this package, and, afterwards, running:
exportfs -ra
(which was probably already run when apt-get installed the package), I
found the frustrating "text file busy" error was gone.
Since I've seen this error in many posts, but never found an answer to it, I
thought I'd post this where I've asked for help, so others can find it via
Google and such in the future. I'm not an expert on NFS, and I really
don't know any other things to do to work with this problem other than what
I've posted. This is what fixed it for me. No more "text file busy"
errors, and no more Wonderland behavior of not updating saved files. If
you're having the same problem, I hope this fixes it . If it doesn't, I
really can't tell you what to try next, but I figure this info alone will
help a good number of people.
Hal