FMS Adv 12 - Error 701 - Instant Web Publishing process has terminated abnormally.

[dsghs]

Just upgraded from FMS Adv 11 to 12.

This is happening once every day or two. Restart web publishing and it will run for another day or two before shutting down. The user is inputting data on a layout right before it happens, but most of the time, on the same layout, inputting the same data, iwp doesn't crash.

[dsghs]

So I just reset it, and as soon as the user gained access and ran a script, it crashed again.

This is the log, looks like my scripts are throwing a bunch of "Web Scripting Errors"

Never had this problem with FMS Adv 11??

[dsghs]

Error codes: 701 Data Access Manager can't find database extension file

[dsghs]

Just happened again 30 minutes after a schedules backup. Seems to not really have anything to do with user/scripts. Just random.

Any ideas?

[dsghs]

Lasted about 4 days this time. Any ideas? I have a robot database that only has one user and two instances of FMPro are remote-signed into the one user account running different scripts... could that present a problem?

[Wim Decorte]

those two robot machines are using web publishing?

Since the error did not happen with the same setup in FMS11, raise a support ticket with FMI so that they can start collecting info on this.

[dsghs]

The robots connect with clients - but the users connect with iwp.

It has been reported : http://reference.fmwebschool.com/FileMaker_Web_Publishing_Engine_Error_Codes

I just reinstalled server. I think maybe something got messed up when I customized the IWP_home.html and IWP_auth.html files in the web publishing engine file. Will see how long it lasts this time and post results.

[Codeus]

Seeing the same errors on one of our Mac Lion Servers w/FMSA 12. Also using custom IWP_Auth and IWP_Home but not convinced these are the cause. Looks to me like it's falling over after the user has logged in and is mooching about the db.

Think Wim is right to raise ticket, just because FM have an error code for it, doesn't mean they know its happening for no good reason since FM12.

[dsghs]

My fix:

I uninstalled FMServerAdv12. Then I manually deleted the Web Publishing folder located in the Filemaker Server folder (I don't remember if uninstalling FMServer deleted it or not, I just made sure it was not there after I uninstalled.)

Then I reinstalled FMServerAdv12.

The only things I messed with inside the Web Publishing folder prior was the IWP error pages (IWP_home.html and IWP_auth.html). I don't know if one of these got corrupted or something else got messed up when I unpacked the IWP package. Note: I DID make these pages custom again after the reinstall and it has still held solid so far.

Anyways, reinstalling the server has corrected the problem for me.

On second thought, I might have deleted the Web Publishing folder before uninstalling - I don't remember - but I guess it shouldn't make a difference

Also using custom IWP_Auth and IWP_Home but not convinced these are the cause. Looks to me like it's falling over after the user has logged in and is mooching about the db.

In my case, the web publishing server would sometimes crash randomly - without any users logged in...

[dsghs]

You have got to be kidding me. It just reared its ugly head...3 weeks later. Repeats every few hours like before.

W T F

[dsghs]

Just another update: I posted the problem on the Filemaker forum and a rep replied:

Hello dsghs:

Thank you for posting.

Currently our Development and Testing department is investigating an issue where the

IWP processes crashes.

The issue involves the use of the back button with tab controls displayed on the layout. Can you confirm if your users are using the web browsers back button with tab controls on the layout?

TSwildcat,

FileMaker Inc.

I do have one tabbed layout used by IWP clients, so I eliminated it (making two separate layouts with tab-like buttons at the top of each). Will report back in the next few days or weeks if I still have the IWP 701 error or not. Crossing my fingers big-time as this crashing problem has become the bain of my existence.

[dsghs]

Crashed a couple days after removing the tabs from the iwp layout... so that didnt work.

For my next attempt at solving this problem, I'm going to manually rebuild the solution. A ghost record popped up a few days ago so maybe the file is corrupt. I'll get back to you guys in a few weeks ugh

[dsghs]

So I was directed to a post made two days ago on the official filemaker forums. It seems that the web publishing process increases memory usage each time an IWP user navigates through layouts, performs finds, enters data, etc. It increases until it uses 2-3 GB of real memory, then crashes. Once restarted, it starts back at 73MB and repeats the increase via aggregated use.

I have tested this on my MacOSX Lion server and found that the process "FM Web Publishing" does in fact behave this way. That is why it seemed random - I only have 3 IWP users that sometimes don't log in for a few days. The crash happens on aggregated use.

Hopefully this has helped (or will help) someone since apparently it has been an IWP issue for 5 years and no one knew what was going on. Also, fingers crossed that Filemaker will come out with a patch soon to correct this headache for IWP devs.

http://forums.filemaker.com/posts/de35658279

[dsghs]

To those who have the memory leak problem with the Web Publishing process and are on a mac, I'm using an Applescript to restart the WPE at 2am everyday. Since my IWP usually went out a couple times a week, this should temporarily workaround the problem. Users with more frequent shut-downs can run it multiple times. Hopefully by the time I get more IWP users, Filemaker will have patched this.

First, open Applescript and copy/paste:

tell application "Terminal"

set currentTab to do script "fmsadmin STOP WPE"

delay 5

do script "y" in currentTab

delay 10

do script "fmsadmin START WPE" in currentTab

delay 10

do script "exit" in currentTab

end tell

Save as a script to some directory.

Open Terminal. Terminal>Preferences>Settings>Shell and change "When the Shell exits" to "Close the window". Quit Terminal.

Open iCal. Create event at whatever time you'd like to restart the server (I do 2am or so). Set reapeating to everyday. Remember, users logged on will be kicked off and will have to log in again. There uncomitted data will also be lost - but it's not like it's not happening with this leak anyway

Set alert on your iCal event to "Run a Script." Point to your new Applescript.

I don't know the Windows equivalent but the command line commands are the same. I also signed up for a free account at www.pingdom.com and set up a monitor pointed to the database directory page (404s when the WPE is not running). It checks it once a minute and upon 404, immediately emails [email protected] which texts me. I then use my iPhone to remote login and hit that button to restart. It's not perfect, but it's better than your users having to tell you about an outage. You can also tell them to wait 5 minutes and it should be back on

This is how I'm dealing with this. Even if you don't have the memory leak problem or are not using Mac, you can still use pingdom.com to let you know within a minute that you need to restart your WPE.

[hedata]

I don't suppose anyone has a fix for this error for Windows? I see dsghs has developed an Applescript to close and reopen the process, is it possible to do the equivalent in Windows Server with a batch file and scheduled task?

[Wim Decorte]

yes it is. The fmsadmin command like works the same on Windows as on Mac. The only caveat on Windows is that you have to specify the full path to where the fmsadmin.exe executable is to call it (or add that path to the Windows PATH variable).

Other than that it works just the same so it's easy to put it in a batch file and use the Windows Task scheduler or the FMS scheduler to run it.

The squence can be made a little more elegant by using only one command and will be something like this:

fmsadmin restart wpe -u user -p adminpw -y

(the username and pw are the ones that you normally use to open the admin console).

[hedata]

Thanks Wim,

Would the following batch file suffice? I must admit I am batch file newbie!

ECHO OFF



start "" "C:Program FilesFileMakerFileMaker ServerDatabase Serverfmsadmin.exe" restart wpe -u admin -p password -y

[hedata]

I solved this by creating a basic task via Windows Task Scheduler to reboot the server each night.

c:windowssystem32shutdown.exe -F -R

This doesn't solve the fmswpc.exe memory leak which may be causing the 701 error messages, but at least stops the process from crashing every other day.

Just make sure you have the 'Auto Start' boxes ticked in FileMaker Server 12 Advanced (Configuration > General Settings > Auto Start).

[Wim Decorte]

Yowsee... I wouldn't make it a one-line script but use the full fmsadmin tools to:

- disconnect any connected clients

- close the files, wait for confirmation that this is done

- then initiate the reboot

Leave the fms config to NOT auto-host databases (using auto-start is DANGEROUS in case of a crash!!!)

do the reverse on a startup script

[dansmith65]

Leave the fms config to NOT auto-host databases (using auto-start is DANGEROUS in case of a crash!!!)

do the reverse on a startup script

How is a startup script set to open databases safer than auto-host?

[Wim Decorte]

because it can check for a preset condition (your own config file, something in the registry) that wouldn't be there on a crash.

[hedata]

Yowsee... I wouldn't make it a one-line script but use the full fmsadmin tools to:

- disconnect any connected clients

- close the files, wait for confirmation that this is done

- then initiate the reboot

Leave the fms config to NOT auto-host databases (using auto-start is DANGEROUS in case of a crash!!!)

do the reverse on a startup script

This is a far more sensible way but I am ignorant of how to configure FileMaker Server to do this!

I'm guessing you'd schedule a 'Script Sequence'? But how do you close the database when the Close File script step is not compatible with the Server? Plus how would you re-open the database files after the server restarts if you turn off auto-start?

[Codeus]

From FM12 Client v3 notes..

Addressed an issue where Instant Web Publishing could crash after a period of use.

Perhaps this is relevant and coming to FMS/A soon too I hope?

[dsghs]

From FM12 Client v3 notes..

Perhaps this is relevant and coming to FMS/A soon too I hope?

We've all got our fingers crossed!

[Codeus]

For what it's worth, I currently have the following script running via a Windows Task Scheduler event every minute.

"C:Program FilesFileMakerFileMaker ServerDatabase Serverfmsadmin.exe" start wpe

If WPE hasn't errored, nothing happens, if it has 701'd, it starts it up again. I swapped to this because I found a daily restart of WPE wasn't doing the trick and atleast this method only restarts it if it has actually crashed, rather than unnecessarily booting clients if it hasn't.

HTH

[dansmith65]

Is th

For what it's worth, I currently have the following script running via a Windows Task Scheduler event every minute.

"C:Program FilesFileMakerFileMaker ServerDatabase Serverfmsadmin.exe" start wpe

If WPE hasn't errored, nothing happens, if it has 701'd, it starts it up again. I swapped to this because I found a daily restart of WPE wasn't doing the trick and atleast this method only restarts it if it has actually crashed, rather than unnecessarily booting clients if it hasn't.

HTH

When WPE crashes, does it create a log entry in Windows Event Viewer? If so, you should be able to trigger your scheduled task by that event.

[Codeus]

When WPE crashes, does it create a log entry in Windows Event Viewer? If so, you should be able to trigger your scheduled task by that event.

 

That's a neat idea.

Looks like FMS/A 12v3 just dropped with a (potential) fix for this.

[Wim Decorte]

because a startup script can be run by a sys admin without having to know too much about FM or FMS.  and it can be run *AFTER* reviewing the log files to see what went wrong and making a decision whether or not to go back to a backup instead of letting FMS open potentially damaged files.

[Codeus]

For me, the FMS/A 12v3  update has *mostly* resolved the 701 issue, apart from in one area.  If a web user accesses a video in a container field it is a guaranteed 701.

 

We have users uploading images and video from FM Go, then accessing it later via a web interface.  Still images still work fine. This is on Windows 2008R2 and we have tested with internal and external container storage.

 

I would be interested if others have had this issue.

[hedata]

FMS 12v3 certainly has resolved the memory leak issue some people were experiencing with the fmswpc.exe process. However many are still suffering 701 errors. Take a look at the FileMaker thread here.

 

My server experiences a 701 error every 5-10 days after the FMS 12v3 update. To lessen the effects on users accessing via IWP, a solution is to create a schedule that restarts the Web Publishing Engine on the 701 Event ID. Certainly not ideal as they still get disconnected, but better than nothing. Others have invested in a program called EventSentry.