FMU Unexpectedly Quitting

[FredReitberger]

Passing this on:

On OS X, this error can also happen if you are running our of vnodes (an

internal system resource). You can check for this with the commands:

sysctl kern.maxvnodes

pstat -T

The first command, sysctl, will display the maximum number of vnodes that

the system can currently have. The second, pstat, will display a couple

of bits of information. The one you want is the number of vnodes

currently in use. If the number of vnodes currently in use is anywhere

near the maximum you are probably having a problem with vnodes.

A vnode is a block of memory in the kernel used to keep track of files on

disk, and other several things, while they are in "active" use. When a

program opens a file, the system requires a vnode for the file and one

for the directory the file is in. Other things the kernel does also

require vnodes. For example doing a DNS lookup takes a vnode. Whenever

the operation is completed, the vnode is freed for reuse.

When a program tries to open a file, and there are no vnodes available,

the open will fail, even if everything else about the operation is fine.

This will cause programs to fail when trying to open a log file, or

writing a backup, or any of several other things. A few things other than

opening files also require vnodes, such as DNS lookups. As virtual memory

usage increases the system will use vnodes to keep track of the virtual

memory. Many other steps can also require vnodes

Certain system programs perform operations that must succeed in order for

the system to continue functioning. When one of their internal operations

fails, because there are no vnodes available, very bad things might

happen. Although everything is supposed to check for that kind of thing,

and try again, not everyone is that careful. Also there are a very few

kernel operations that must have a vnode right now, and can not wait for

one to be freed. If one of those happens and there isn't a vnode

available, you will get a kernel panic.

The solution is to tell the system to allocate space for more vnodes. The

command:

sudo sysctl -w kern.maxvnodes=20000

will raise the limit to 20000 till the next reboot. This must be run by

an admin user and will prompt for a password. You should watch the output

of:

pstat -T

to make sure that that is really enough. You want there to be a few

thousand free when running all of the apps you are every planning to run.

If not, raise the 20000 to something higher.

Hope this helps

[kenneth2k1]

This is interesting, Fred.

On a side note, unexpected quits can also be caused by bad memory. If you have a program like TechTools, then you could run it and see if you maybe have a bad RAM chip.

In my experience, FM 5.5 or 6 runs the best on Windows 2000. BUT, we have been running FMU 6 on OSX Server (from 2.1 to 2.8) for about a year now and have had no problems whatsoever.

Could Panther be the answer you think???

[bigfundj]

Released on 10/24/03, FileMaker Web Companion 6.0v2

ftp://ftp.apple.com/filemaker/Updaters/MacOSX/wc_60v2_osx_update.sit

From the Read Me file:

Fixes a problem that caused Web Companion to become unstable or quit when sharing databases from Mac OS X 10.2.

[dwal]

Panther appears to be the answer for Macintosh. Last Friday I upgraded our server from Jaguar to Panther. There have yet to be any problems! Prior to this FileMaker Unlimited v6 would stop responding after 36 hours or sometimes sooner.

[tmoney]

bigfundj said:

Released on 10/24/03, FileMaker Web Companion 6.0v2

ftp://ftp.apple.com/filemaker/Updaters/MacOSX/wc_60v2_osx_update.sit

From the Read Me file:

Fixes a problem that caused Web Companion to become unstable or quit when sharing databases from Mac OS X 10.2.

I wonder if Filemaker will be kind enough to fix that same problem in the 5.5 Web Companion. I'm sure they know it's there too - and I'm sure they fixed the current version first. Anybody have any idea if they will go back and fix the 5.5 version now?

[mlindal]

It has been a while since I have posted - but it is nice to know that others now have the same troubles we struggled with for the past 2 years.

Under 4 and OS 9, (FM Server on NT) - the solution was bullet proof.

Upgraded to 5.0 and Windows 2000 (Web companion on OS9) - bullet proof for a while - then Windows 2000 had a Nambda virus patch applied and the crashing began. We upgraded to OS X, no good, FM5.5 - no good, and finally sadly turned in our Mac and ran it on Windows 2000. Better stability but still needs a reboot once a week. Now the crashing is increasing over the past month.

I am still amazed that Filemaker has not addressed this issue better as it is obvious that many are having troubles (anyone for a clash action lawsuit ;-) )

I am hoping they come out with a 6.02 patch for Windows soon and hopefully there is some news that Version 7 will be more stable. It is getting tough to preach "Filemaker is great" when the site has to be rebooted.

Anyway - no solutions here - we have tried everything all have suggested and now we wait for Filemaker to come up with a fix.

Perhaps Panther, FM6.02 unlimited, etc is the solution...

[jfurness]

I plan to upgrade to Panther Server with the latest version of Filemaker 6.0v2 Although i haven't had Filemaker quit unexpectedly since i installed the update (2 days ago) Filemaker has hung twice. Here the databases and the application are open, in fact i can swop between OSX apps and Filemaker, but there is no response at all from Filemaker, force quit and relaunch is the only fix. Might be something to do with vnodes.

I do wonder whether the latest FM update works in 5.5, are the web companion plugins written just for FM 6.0? Has anyone tried it?

[Anatoli]

RE: Upgraded to 5.0 and Windows 2000 (Web companion on OS9) - bullet proof for a while - then Windows 2000 had a Nambda virus patch applied and the crashing began.

We didn't have slight issue with FMU 5 and NT4 server. How you connect the W2000 to WC on OS9? Is it with Web Server Connector? In that case maybe there is conflict between patch, IIS and WSC. WSC is hmm -- not the best application around

[jfurness]

I have now taken the bold step of Installing Panther server running Filemaker Pro 6.0 Unlimited. So far looking good for stability, by now I would have expected at least 2 crashes in the four hours it have been running. Not brave enough to say it's fixed just yet though!

[kenneth2k1]

Did you reinstall Win2k from scratch after the Nimbda virus? Because the patch will DELETE any file affected. This includes app and system files. That virus is also able to spread to other PCs on the network. So crashing might result from that.

[ibiubu]

jfurness...

I too have had a lot of the unexpectedly quitting of v6 of unlimited on OSX. Both version 10.2.6 and 10.2.8. Was curious what updating to 10.3 has done for your problem.

LR

[Anatoli]

Good point.

BTW -- it is Nimda. Read it backwards

[sydlexic]

Greetings from a new member...

I recently moved from a Win2K server to a dual-G4 XServe (running OS X 10.3.1, Apache 1.3.28, PHP4.3.4, FX.php and FMU 6.0v2). While configuring the machine, everything seemed to work fine, but as soon as we swapped servers I started getting the FM freezes that jfurness has experienced. It was happening 3-4 times/day, and got so bad that we went back to the Win2K machine until we get it sorted out. We've got a FM support tech working on it, but he seems as baffled as we are.

Has anyone found a solution for this problem?

I've got another one that perhaps someone has seen: Sometimes (let's say "semi-reliably") FMU will just quit cold when a particular PHP file sends its request to Web Companion. We have to restart FMU and go through the whole file consistency check process. It happens on both the Win2K and Apple servers. The file is more complicated than most, but not essentially different from others that work fine. Does this sound familiar to anyone?

Regards,

sydlexic

[kenneth2k1]

Hi:

I noticed that you said that your version is 6.0v2. There is a 6.0v4 that I would try upgrading just to be sure.

[sydlexic]

That was a typo. I'm using 6.0v4, with the recently updated Web Companion files.

[Steve Hannah]

We are running FileMaker unlimited 5.5v1 with the web companion 5.5v4 on Mac OSX 10.2.8 Server. We are experiencing crashes 5 to 6 times per week (unexpectedly quitting). We are serving approximately 25 databases and we have tried recovering and compressing all of these databases in the hope that it was a corrupted database that was causing the problem. We have also tried this one 2 different machines running fresh installs of OS X Server. Same results. The following is a readout of the crash log from apple system profiler. Has anyone run across this before... any ideas.

Date/Time: 2004-03-03 08:44:17 -0800

OS Version: 10.2.8 (Build 6R73)

Host: Xavier

Command: FileMaker Pro

PID: 585

Exception: EXC_BAD_ACCESS (0x0001)

Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0 Crashed:

#0 0x04f98788 in 0x4f98788

#1 0x04f20b4c in wc::OTTCPSocket::Notification::Run( (void))

#2 0x04f8c910 in wc::OTCarbonTCPSocket::BufferCompletion( (wc::BufferRef const &, long, unsigned))

#3 0x04f20034 in wc::OTTCPSocket::In::Run( (void))

#4 0x04eedea0 in Run__Q22wc13TaskQueueImplFRCQ22wc15Ref<Q22wc4Task>

#5 0x04ede444 in wc::TaskQueueImpl::Run( (void))

#6 0x04ede738 in wc::STMacCondition::WaitOnQueuedTasks( (void))

#7 0x04eded8c in wc::STMacScheduler::ShutDown( (void))

#8 0x04ef1e28 in wc::SchedulerImpl::Quit( (void))

#9 0x04e9aff4 in wc::AccessCompanionImpl::Stop( (bool))

#10 0x04e9e26c in wc::WebCompanionImpl::Stop( (bool))

#11 0x04eae014 in NSRV_NetworkStop(void)

#12 0x04e07674 in FMExternCarbonCallProc

#13 0x003cf690 in CallFMExtern

#14 0x003d0d28 in FMXC_ChangePlugInState(short, unsigned char)

#15 0x003d12a4 in fmxShutdownPlugin(int)

#16 0x003d1370 in FMXC_Shutdown(void)

#17 0x0038aa64 in DOC_Shutdown(void)

#18 0x003bfc20 in CFMProApp::ExitInstance(void)

#19 0x005c70a8 in 0x5c70a8

#20 0x003bee38 in main

Thread 1:

#0 0x9000508c in syscall

#1 0x90515d0c in BSD_waitevent

#2 0x905156dc in CarbonSelectThreadFunc

#3 0x90020c28 in _pthread_body

Thread 2:

#0 0x9003e9a8 in semaphore_wait_signal_trap

#1 0x9003e7c4 in _pthread_cond_wait

#2 0x9051dbf0 in CarbonOperationThreadFunc

#3 0x90020c28 in _pthread_body

Thread 3:

#0 0x9003e9a8 in semaphore_wait_signal_trap

#1 0x9003e7c4 in _pthread_cond_wait

#2 0x905259e0 in CarbonInetOperThreadFunc

#3 0x90020c28 in _pthread_body

Thread 4:

#0 0x9003e9a8 in semaphore_wait_signal_trap

#1 0x9003e7c4 in _pthread_cond_wait

#2 0x9023317c in TSWaitOnSemaphoreCommon

#3 0x9024890c in AsyncFileThread(void*)

#4 0x90020c28 in _pthread_body

PPC Thread State:

srr0: 0x04f98788 srr1: 0x0000f030 vrsave: 0x00000000

xer: 0x00000000 lr: 0x04f022a4 ctr: 0x04edfe68 mq: 0x00000000

r0: 0x04edfe68 r1: 0xbffff140 r2: 0x04ff0000 r3: 0x05054028

r4: 0xbffff1d8 r5: 0x00000004 r6: 0x0000000c r7: 0x01000000

r8: 0x905725ac r9: 0x00000001 r10: 0x00000002 r11: 0xa00044b0

r12: 0x00000000 r13: 0x00000000 r14: 0x00000000 r15: 0x00000000

r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x00000000

r20: 0xbffffe44 r21: 0x05052ab0 r22: 0x0501552c r23: 0xffffffff

r24: 0xbffff344 r25: 0xbffff338 r26: 0x0503d7d0 r27: 0x05a5ba40

r28: 0x0503d7a0 r29: 0xbffff1d8 r30: 0x050160d8 r31: 0xbffff140

[PBainbridge]

After many unexpected quits in OSX 10.1.5 and 10.2 with both FMU 5.5 and 6.0, the Web Companion 6.0v2 patch from Filemaker (see http://www.filemaker.com/support/updaters.html) , solved all our problems.

We have been running for months now without a hint of trouble. For anyone still having difficulty, I would seriously recommend upgrading to 6.0 and installing all the updates

[mindtpi99]

I had problems with FMU6 quitting off FMS 5.5 - upgrading the web companion seems to have fixed the problem for me. Are you running FMU and FMS on the same system? I understand that this may cause problems and is not recommended.

[Curtis Deprez]

hello, i am in process of putting up site on new server. Dual processor XEON 3.06 GHZ with 1.5 GB RAM. Filemaker 5.5 unlimited running the DB. the site on old server P3 800 MHZ with 786 MB Ram runs great. when i put new more robust server into production, FM stops with no warning. earlier in the thread someone had mentioned this. I was wondering if there is a limit to what FIlemaker can actually handle.

The site is running on WIndows 2000 standard server - IIS 5.

ANY information is appreciated.

[Will]

Hi -

What do you mean "stops with no warning" - do you mean the application locks up?

Have you applied any necessary FileMaker updates?

Have you checked the Windows event logs?

Will

[Curtis Deprez]

Hi Will,

Perhaps i should have been more technical. the XEON chip uses hyperthreading which i know FIlemaker does not take advantage of. I did not know of it causing problems. Once the CPU usage reaches more than 50% on the webserve, the Filemaker client quits or needs to be restarted.

Applying the necessary updates and checking the event logs? thank you and of course.

i have disabled hyperthreading on the server and i am running tests to see if this resolves my issue.

is there anyone out there running a website with IIS 5 and filemaker 5.5 Unlimited using XEON technology? 3 GHZ. i heard at a certain point it switches to 64 bit which the application won't handle.

[RichB]

The latest version of WC (6.0v3) has really worsened the crashing problem for us.

ftp://ftp.apple.com/filemaker/Updaters/MacOSX/wc_60v3_osx_update.sit

Reverting back to 6.0v2 hasn't helped. Will have to try the vnode solution...

Anyone else having problems now with Web Companion 6.0v3 crashing?

[Will]

Curtis -

I am also running FM 5.5 Unlimited on a Windows 2000/IIS Server. But it is a single processor P-III. Occasionally I have noticed FM using 95-99% of the processor. This started happening in the last 3 weeks or so. The last time this happened was about 2 years ago and the culprit was a new version of Netscape browser - whenever that browser connected to the site FM CPU usuage locked at 99% - I don't recall if I was using 5.0 or 5.5 Unlimited at that time.

Will

[Steve T.]

Just FYI... While working on my events calendar project, I discovered a weird UNEXPECTEDLY QUIT error yesterday whenever I auto-sent mail from one of my pages for the 2nd time. It's really strange.

Other than that, on our Mac systems we disabled the software updates utility and the auto-setting of the date and time and it may have helped some... hard to say. Still, 1 of our servers goes down maybe 1/month and the other one a little more but comparable... the former is on 10.2.8 and the latter is on 10.3.?. Both use FMP-U 5.5.

--ST

[elab1]

thats my problem too.. when ever a web client sends requests on FM. it quits unexpectedly.. I really dont know what the problem is..

[ibiubu]

I had a problem like this. Sometimes when a request was sent, FM would just quit. Oddly enough for me, it was my -error page. I still dont know what it was, but if a request was sent and something was amiss, the user would get sent to the -error page instead of the -format page. FM would then just quit.

Something was coded strange in my -error page. I rebuilt it from scratch, and now it no longer causes a crash. So if I had my -error page causing FM to quit, I wonder if there are any of your -format html files that are causing FM to quit?

Wish I could be more specific, but I never did find what it was on my original -error page. Double check your html pages. Maybe hidden characters or incorrect cdml links.

LR

[kfutter]

We've been having quitting problems similar to what's been described so far in this thread - about every second day (sometimes more often), FMU 6v4 would 'unexpectedly quit' for no apparent reason (running on Mac OS X 10.2.8).

To cut a long story short, what eventually fixed it for us (fingers crossed, so far so good!) is upgrading Web Companion to the latest 6v3 patch.

Just thought I'd add our experience to the list ...

Cheers,

Kevin Futter

[iMarcW]

I've been following this lengthy post for years and still don't get reliable performance out of our FMU 6.x server, so now that I've come up with an AppleScript that seems to fix the problem, I thought I would share it.

The first part checks whether FileMaker is running at all, in case it has been quit, unexpectedly or otherwise. The "else" part uses a simple call for the version number to determine whether the application is responding (this is the problem I have most often--spinning beach ball, etc.). The 10-second timeout gives enough time for any current processing of web transactions to finish before it assumes FMU is hung. It will also kill FMU if a Define Fields or other dialog is open which prevents the script (and web users) from communicating with the databases. The OpenDBsOnCrash.fp5 file is an opener file, but the opener script also creates a new record in that database with the current date and time, so you get a log of server restarts. About the only thing it doesn't check for is whether an individual database has been closed, but that's not a problem I typically have.

I used Cronnix to create a crontab which runs the script every minute. My thanks to the folks on the message boards at MacScripter.net for helping me figure some of this out.

The script:

set exists_ to false

tell application "System Events"

set exists_ to exists process "FileMaker Pro"

end tell

if exists_ is false then

tell application "Finder"

open file "Users:Username:OpenDBsOnCrash.fp5" of startup disk

end tell

else

set v to ""

try

with timeout of 10 seconds

tell application "FileMaker Pro" to set v to version

end timeout

end try

if v is "" then

do shell script "killall "FileMaker Pro""

set exists_ to true

tell application "System Events"

repeat until exists_ is false

delay 2

set exists_ to exists process "FileMaker Pro"

end repeat

end tell

tell application "Finder"

open file "Users:Username:OpenDBsOnCrash.fp5" of startup disk

end tell

end if

end if

[iMarcW]

Having posted the above script before I actually got a chance to see if it stopped crashes, I thought I would provide an update on how it worked, now that I've actually had a lot of traffic.

Simply put, it does what it's supposed to do--it has crashed about 4-5 times in the last two months (almost always in the middle of the night, when traffic is virtually nonexistent), and the script always restarted it successfully, although a couple times it was necessary to restart 3-4 times in a 10-20 minute period. Overall, the number of hangs is down from this time last year, which might be because of the script "tickling" the FMU app every minute or because I upgraded the RAM from 512 to 1 GB since then.

Anyway, our customers are happy because downtime has been effectively eliminated. So we're happy too.

[Steve T.]

Hmm... AppleScript, eh? Thanx, iMarc... I'll give that a try soon and see how it works with FMU 5.5 and will post my success story here (I hope). Our crashes tend to be overnight or over the weekend as well so I used to think it was googlebots/spambots/spiders/crawlers... now I think it's a variety of things and not just 1 problem. One problem I've had from these crashes, though, is that once in a while, one of the db's will be corrupted and I have to do a RECOVER on it before it's operational again. Make sure you follow Vaughan's advice and backup your files; keep an empty shell, too, if you can.

Our upgrade to Panther 10.3 has reduced our crashes dramatically, however, so it may be a while before I'll even know if your solution worked for me.

BTW, is your crontab file a user-based crontab in the logged-in user's home directory somewhere or is it the main system cron file in the root area? And for those of you in the audience wondering what the heck a crontab file is, I think it's like a unix-based timed script system. In Mac OS X, for example, Apple has a number of tasks in cron that are performed fairly regularly to help keep your system running smoothly... housekeeping stuff the user usually isn't even aware of. Earlier in this thread, I mentioned using cron to reboot the server every day in the wee hours. While this worked for us, some users were experiencing too many breaks in services during the day so iMarc's solution should work better for Mac users. Windows has a scheduler but I'm not sure what can be done about the equivalent to the AppleScript shown.

Thanxagain for the post!

--ST

[iMarcW]

I'm pretty sure the crontab is user-based--if I were logged in as another user, I probably wouldn't be running the databases anyway.

I suspected spiders for a while, too--I blocked Google access to all the FM-generated pages for awhile, but it didn't seem to make much difference. Panther probably helped too, but... That's why this whole problem is so frustrating, there's just so many variables and nothing seems to make the problem disappear completely.