Log in to create and rate content, and to follow, bookmark, and share content with other members. Not a member? Join Now!

AnsweredAssumed Answered

Oh FMSE, oh FMSE, how convoluted are thy behaviours

Question asked by StephenWonfor on Dec 12, 2018
Latest reply on Feb 12, 2019 by StephenWonfor

Like • Show 0 Likes0
Comment • 22

Gathering a few threads on this topic into this one - perhaps to make a toque to cover up this annoying mess.

https://community.filemaker.com/thread/176454

https://community.filemaker.com/thread/186610

https://community.filemaker.com/thread/191294

The plot:

5 clients with their own in-house FMServers.

Box 1 FMS16.0.4 on OSX 12.4

Box 2 FMS16.0.4 on OSX 12.4

Box 3 FMS16.0.4 on Windows Server 2016

Box 4 FMS16.0.4 on Windows Server 2012

Box 5 FMS16.0.4 on OSX 13.6.

Boxes 1 and 3 are suffering from either or both of "ghost connections" or the FMSE (Filemaker Script Engine) suddenly quitting. Box 1 even reports, at times ( roughly 14 day intervals), that "FileMaker Server is now awake. All schedules will now be resumed." - even though every known energy saver setting is OFF. I have read of this happening way back in FMS 11. Box 4 suffered from ghosts and FMSE issues after upgrade from FMS 14 to 16 - rebuilding all serverside scripts seemed to fix it - gets ghosts perhaps fortnightly now. Box 3 is getting FMSE suddenly OFF after 6 months of quiet. Wow, rather sounds like describing a group of different volcanos and their eruptive states!

Fixes:

Reboot the machine, stop/start the FMSE, rebuild all server scripts.

Also looking to find some code that we can call via CRON or TaskScheduler that would stop/start the FMSE, maybe disconnect ghosts, maybe close dbs and reboot server.

Question:

For those who have ventured up to FMS 17 - does this sort of "inconvenience" still occur there? How are things in the Cloud?

Stephen

"Beware of bugs in the above code; I have only proved it correct, not tried it." - Donald E. Knuth.

Ghosts illustrated

No one else has this question

Outcomes

22 Replies

StephenWonfor Dec 12, 2018 1:21 PM
Mark Correct
Correct Answer
1. Try setting FTP from 7 am to 9 am.
2. Swap out plugin with beta - not yet
3. disable the AR and invoice overnighters then renable
4. despair.
5. disable Dropbox routine
6. try server service off then on - 9 pm prior to check midnight runs to see how they do Nov 29
7. overnights till aborted. Run fine from console when asked.
8. reboot server.
9. overnight still hang. run ok from admin console.
10. run at a different time?
11. now getting server sleep
12. rebooted a number of time over the weekend
13. rebooted 6 am Dec3
14. ghost users again - the FTP routine
15. the only ghosts ever are the FTP ones
16. new version of FTPeek i stalled - now it hangs up
17. put old one back and restart FMS - no reboot yet
18. restart FMS around 9 pm - overnights still hanging - run manually via admin console no issues
19. OK next morning re: the FTP routine
20. ghosts again 5 pm - reboot as server service off not convincing
21. ghosts at 6 am - reboot server
22. another reboot due to ghost connections - basically no user load
23. reboot - many ghosts no users
24. many ghosts - disable calling script
Like • Show 0 Likes0
Actions
alecgregory Dec 12, 2018 3:09 PM
Mark Correct
Correct Answer
I am seeing both issues (ghost connections and FMSE stopping on its own) with FileMaker Server 17.0.2 on High Sierra. So an upgrade may not help you.
Like • Show 0 Likes0
Actions
james_quiggins @ alecgregory on Dec 12, 2018 3:22 PM
Mark Correct
Correct Answer
Ghosts happen in the UAC when FMSE crashes with active sessions, you can clean this up by running fmsadmin restart adminserver in terminal. I've associated this thread with the report of this behavior within our internal system.

For the crash, could you post some crash reports from Library/Logs/Diagnostic Reports? I'll do a search and see if we have any info on the specific crash.

James
Like • Show 0 Likes0
Actions
alecgregory @ james_quiggins on Dec 12, 2018 3:31 PM
Mark Correct
Correct Answer
Thanks for the reply James. I have not experienced a FMSE crash and ghost connections on the same server. I have attached the crash report for the server that had the FMSE engine crash.

The server with ghost connections has no log files for an FMSE crash.
Attachments
- fmserverd_2018-12-10-145131_devtestkaimingorg.crash.zip22.4 KB
Like • Show 0 Likes0
Actions
james_quiggins @ alecgregory on Dec 12, 2018 3:40 PM
Mark Correct
Correct Answer
alecgregory wrote:

Thanks for the reply James. I have not experienced a FMSE crash and ghost connections on the same server. I have attached the crash report for the server that had the FMSE engine crash.

The server with ghost connections has no log files for an FMSE crash.
Thanks, Is your sever with ghost connections using an external odbc based data source(ESS)?

This crash happened during shutdown. We can reproduce almost the exactly same stack by running 1000 user test and then shutting down after. I've associated this report with the defect.

If you have any different call stacks please add them.

Thread 56 Crashed:
0 libsystem_pthread.dylib      0x00007fff55fa5eda pthread_mutex_trylock + 0
1 com.filemaker.support.framework 0x0000000111133e2e Draco::LongWaitMutex::Grab(Draco::Thread*) + 28
2 com.filemaker.dbengine.framework 0x0000000110a02eb4 Draco::DBLockMgr::LocalUnlock(Draco::DBLockUser const&, Draco::RefCountedObjPtr<Draco::DBLockPathObj> const&, Draco::DBLockType, Draco::DBLockArgs const*) + 148
3 com.filemaker.dbengine.framework 0x00000001109fb744 Draco::DBLockMgr::UnlockPartialPath(Draco::DBInternalLock*) + 150
4 com.filemaker.dbengine.framework 0x00000001109fb493 Draco::DBLocksPerUser::KillAllLocks(Draco::DBLockUser const&, int, bool) + 595
5 com.filemaker.dbengine.framework 0x00000001109fbe70 Draco::DBLocksPerUserTable::KillAllLocks(Draco::DBLockUser const&, int, bool) + 164
6 com.filemaker.dbengine.framework 0x00000001109fbd77 Draco::DBLocksPerUserTable::KillAllLocks() + 153
7 com.filemaker.dbengine.framework 0x0000000110a0457b Draco::DBLockMgr::~DBLockMgr() + 53
8 com.filemaker.dbengine.framework 0x00000001109a2ba3 Draco::DBEngineController::Shutdown() + 191
9 com.filemaker.dbengine.framework 0x000000011099f35a Draco::DBEngineController::~DBEngineController() + 28
10 com.filemaker.dbengine.framework 0x000000011099f484 Draco::DBEngineController::~DBEngineController() + 14
11 fmserverd                    0x000000010f377e6c EngineMgr::EngineShutdownFilesClosed() + 908
12 fmserverd                    0x000000010f3389fb EngineMgr::EngineCheckShutdown(FMS::EngineShutdownMsg*) + 187
13 com.filemaker.FMS.framework 0x000000010fe64f29 FMS::ComponentBaseThread::Main() + 281
14 fmserverd                    0x000000010f330776 EngineMgr::Main() + 326
15 com.filemaker.support.framework 0x00000001111368e5 Draco::Thread::RunThread() + 49
16 com.filemaker.support.framework 0x0000000111135ba9 Draco::Thread::ThreadUnixProc(void*) + 265
17 libsystem_pthread.dylib      0x00007fff55fa5661 _pthread_body + 340
18 libsystem_pthread.dylib      0x00007fff55fa550d _pthread_start + 377
19 libsystem_pthread.dylib      0x00007fff55fa4bf9 thread_start + 13
Attachments
- fmserverd_2018-03-01-114156_OldOakMac.crash.zip21.9 KB
Like • Show 0 Likes0
Actions
alecgregory @ james_quiggins on Dec 12, 2018 3:55 PM
Mark Correct
Correct Answer
Hi James,
This crash happened during shutdown.
It seems strange that the crash was on shutdown, it may be a different one from the one i was thinking of. However, I can't find any more FileMaker crash logs for that server. What happened was:
1) I attempted to run a script on server (using PSoS)
2) I got the error code 812 (exceeded host's capacity). This is happens from time to time, and is what I used to determine whether the FMSE has crashed
3) I restarted FMSE using the command line tool and tried again. The PSoS ran without an error this time.
Thanks, Is your sever with ghost connections using an external odbc based data source(ESS)?
There is an ODBC Data source.
- There is a Server Scheduled script that runs every 5 minutes. It imports data from a ESS table to a FileMaker table using the Import Records script step.
- The import happens via a Calculated SQL query. I have never seen any ghost connection for this process. It usually takes about 20 seconds to run and then disconnects.
- None of the users who were seeing ghost sessions ever connect to a file with an external ESS source, however, they do connect to the file that includes the table that is the import destination for the SQL data.
Hope this helps. Let me know if you need more info.
Like • Show 0 Likes0
Actions
james_quiggins @ alecgregory on Dec 12, 2018 4:04 PM
Mark Correct
Correct Answer
alecgregory wrote:

Hi James,
This crash happened during shutdown.
It seems strange that the crash was on shutdown, it may be a different one from the one i was thinking of. However, I can't find any more FileMaker crash logs for that server. What happened was:
1) I attempted to run a script on server (using PSoS)
2) I got the error code 812 (exceeded host's capacity). This is happens from time to time, and is what I used to determine whether the FMSE has crashed
3) I restarted FMSE using the command line tool and tried again. The PSoS ran without an error this time.
The error handling could be improved for this scenario. Host capacity exceeded is output when the process isn't running and a better error should happen. Your host capacity could've been exceeded and the error be legitimate, what is your maximum script session setting?
There is an ODBC Data source.
There is a Server Scheduled script that runs every 5 minutes. It imports data from a ESS table to a FileMaker table using the Import Records script step.
The import happens via a Calculated SQL query. I have never seen any ghost connection for this process. It usually takes about 20 seconds to run and then disconnects.
None of the users who were seeing ghost sessions ever connect to a file with an external ESS source, however, they do connect to the file that includes the table that is the import destination for the SQL data.
Hope this helps. Let me know if you need more info.
This actually might help a ton, this is one I cant seem to reproduce. We have numerous people reporting it over the years, perhaps starting in FileMaker 14. Typically their configurations are much more complicated and whats done via ESS isn't clear at all like yours. Your information might prove infinitely helpful.

What I've observed happening is actually the thread that is responsible for cleaning up idle sessions halts. This means that any client that crashes or a Go client that is backgrounded or goes to sleep doesn't get cleaned up resulting in a ghost session that persists forever. Does this sound like what you're experiencing?
Like • Show 0 Likes0
Actions
alecgregory @ james_quiggins on Dec 12, 2018 4:25 PM
Mark Correct
Correct Answer
James Quiggins wrote:

alecgregory wrote:

Hi James,
This crash happened during shutdown.
It seems strange that the crash was on shutdown, it may be a different one from the one i was thinking of. However, I can't find any more FileMaker crash logs for that server. What happened was:
1) I attempted to run a script on server (using PSoS)
2) I got the error code 812 (exceeded host's capacity). This is happens from time to time, and is what I used to determine whether the FMSE has crashed
3) I restarted FMSE using the command line tool and tried again. The PSoS ran without an error this time.
The error handling could be improved for this scenario. Host capacity exceeded is output when the process isn't running and a better error should happen. Your host capacity could've been exceeded and the error be legitimate, what is your maximum script session setting?
The max is 500 and it's a dev server so never more than a couple of clients connected. In this case I explicitly checked the number of connected sessions when i got the error and it was 0.
What I've observed happening is actually the thread that is responsible for cleaning up idle sessions halts. This means that any client that crashes or a Go client that is backgrounded or goes to sleep doesn't get cleaned up resulting in a ghost session that persists forever. Does this sound like what you're experiencing?
It has striking similarities to what I saw. These are almost all clients connected over Wi-Fi so there is a fair bit of sleeping and disconnecting (note, though, that there is no idle timeout set for the clients, an iOS client could in theory be connected forever!). As well as this, the opening procedure for the mobile clients opens a couple of connections in quick succession:

1) Open offline iOS App SDK app
2) Connect to file 1 and run script
3) Disconnect from file 1 (uses Close File script step once script has completed)
4) Connect to file 2
Like • Show 0 Likes0
Actions
CarlSchwarz Dec 12, 2018 5:20 PM
Mark Correct
Correct Answer
or the FMSE (Filemaker Script Engine) suddenly quitting
One cause of server components shutting down, including WPE, CWP, and FMSE is low resources such as RAM. 100% utilisation is not necessary, just low. I'm not saying that is the issue in your case but it is worth looking at.
2 people found this helpful
Like • Show 0 Likes0
Actions
james_quiggins @ alecgregory on Dec 12, 2018 5:46 PM
Mark Correct
Correct Answer
alecgregory wrote:

James Quiggins wrote:

alecgregory wrote:

Hi James,
This crash happened during shutdown.
It seems strange that the crash was on shutdown, it may be a different one from the one i was thinking of. However, I can't find any more FileMaker crash logs for that server. What happened was:
1) I attempted to run a script on server (using PSoS)
2) I got the error code 812 (exceeded host's capacity). This is happens from time to time, and is what I used to determine whether the FMSE has crashed
3) I restarted FMSE using the command line tool and tried again. The PSoS ran without an error this time.
The error handling could be improved for this scenario. Host capacity exceeded is output when the process isn't running and a better error should happen. Your host capacity could've been exceeded and the error be legitimate, what is your maximum script session setting?
The max is 500 and it's a dev server so never more than a couple of clients connected. In this case I explicitly checked the number of connected sessions when i got the error and it was 0.
What I've observed happening is actually the thread that is responsible for cleaning up idle sessions halts. This means that any client that crashes or a Go client that is backgrounded or goes to sleep doesn't get cleaned up resulting in a ghost session that persists forever. Does this sound like what you're experiencing?
It has striking similarities to what I saw. These are almost all clients connected over Wi-Fi so there is a fair bit of sleeping and disconnecting (note, though, that there is no idle timeout set for the clients, an iOS client could in theory be connected forever!). As well as this, the opening procedure for the mobile clients opens a couple of connections in quick succession:

1) Open offline iOS App SDK app
2) Connect to file 1 and run script
3) Disconnect from file 1 (uses Close File script step once script has completed)
4) Connect to file 2
Since it's a dev server, could you set your odbc script to run over and over again and see how quickly you can reproduce? Every hour or so just try to login to a database with go then put the phone to sleep. See if the connection gets cleaned up.
Like • Show 0 Likes0
Actions
james_quiggins @ james_quiggins on Dec 12, 2018 5:52 PM
Mark Correct
Correct Answer
Maybe try setting up 3 or 4 server side script sessions doing this import every minute.
Like • Show 0 Likes0
Actions
StephenWonfor Dec 13, 2018 8:31 AM
Mark Correct
Correct Answer
An update. Box 1 has not had ghosts or FMSE quits over the past 4 days. Nothing has been done to it other than monitor it. No ESS connections. The only add-on is 360Works FTPeek (running fine for years) that does a simple FTP routine at 10 minute intervals during business hours. I note that Activity Monitor shows (sometimes) 50-60% memory use during the routine. Other times barely a blip. The system has 16 GB RAM with 2.8 GHz Intel Core i5.
Also ran across this thread about the fmsased.
FMS13 fmsased Memory Leak - fmsased grows until restart when using scheduled scripts
Like • Show 0 Likes0
Actions
wimdecorte @ StephenWonfor on Dec 13, 2018 9:00 AM
Mark Correct
Correct Answer
Are you using that plugin through PSoS calls, or schedules that may be overlapping?
Like • Show 0 Likes0
Actions
StephenWonfor @ StephenWonfor on Dec 13, 2018 9:01 AM
Mark Correct
Correct Answer
Box 3. Going through server logs and ran across this:
Schedule "Server - Lock Financial Record" scripting error (509 [406038x]) at "RMNMainDB : ServerSide - Lock Invoices, Details, Payments : 42 : Go to Record/Request/Page". Routine ran just before or during or caused and FMSE hangup.
What might [406038x] be about? Error 509 "field requires valid value" can be reviewed.
Like • Show 0 Likes0
Actions
StephenWonfor @ wimdecorte on Dec 13, 2018 9:05 AM
Mark Correct
Correct Answer
Wim

My plugin routines all run serverside. In the Box 1 case there is just one that runs a lot - 10 minutes during business hours - usual execution is about 75 seconds. All backup and serverside script calls have been scheduled to not overlap, all have abort time limits set.

Stephen

---

"Don't let yesterday take up too much of today" - Will Rogers
Like • Show 0 Likes0
Actions
taylorsharpe @ alecgregory on Dec 13, 2018 9:17 AM
Mark Correct
Correct Answer
alecgregory wrote:

I am seeing both issues (ghost connections and FMSE stopping on its own) with FileMaker Server 17.0.2 on High Sierra. So an upgrade may not help you.

I've seen it in the past, but I've never seen FMSE crash in 17 and I monitor about 15 servers regularly. Also, I now get my list of users via the new Admin Console API, which seems rock solid.

While it sucked, in the past when we had FMSE crashing problems, we'd have a chron job execute a FMSADMIN START FMSE regularly. It was a workaround, just hated having to do it.

I really thought the FMSE problem had been fixed by 17. At least I'm not seeing it fortunately.
Like • Show 0 Likes0
Actions
StephenWonfor @ taylorsharpe on Dec 17, 2018 9:46 AM
Mark Correct
Correct Answer
An update on my original post.

Box 1 has simply stopped having issues. Last one was 8 days ago. NOTHING at all has been done to this box.
Box 3 started, out of the blue, having FMSE stopping issues. No STOP in the logs but scripts all started to report "...aborted, time limit exceeded or server stopped". Logs did show a script, some years old, that started getting 509 errors. A lot of them. Schedule "Server - Lock Financial Record" scripting error (509 [505781x]). The FMSE was imperiled and stopped. Simple routine - just executes a FIND for unlocked records and locks them - change "lockout" to "lockon". Field is text - 509 claims a data mismatch. This was "fixed" (very inappropriate term) by placing the field in question onto a neutral layout (no triggers, no fields) although neutrality is now violated by the presence of this field. The script now reports only "non-errors" - no records found and the like. I can see why the "Wedge" has been quiet about this problem - how on earth can one troubleshoot this when it comes and goes. It is unfortunate to be among the few that it happens to.

Best advise so far has been a CRON or TaskScheduler routine that starts and stops the FMSE.

Addition: Had 3 ghosts on Box 3 today. Unable to disconnect them via admin console. Stopped FMSE and they disconnect immediately.

Stephen
Like • Show 0 Likes0
Actions
alecgregory @ james_quiggins on Dec 17, 2018 9:57 AM
Mark Correct
Correct Answer
Since it's a dev server, could you set your odbc script to run over and over again and see how quickly you can reproduce? Every hour or so just try to login to a database with go then put the phone to sleep. See if the connection gets cleaned up

Maybe try setting up 3 or 4 server side script sessions doing this import every minute.
Unfortunately the ODBC is only on the production server, which is where we saw the ghost connections. To clarify and summarize:
- The DevTest server had issues with error 812. This is the server I attached a crash log for, although you determined that this was a crash on shutdown so it is likely not related to the 812 error.
- The production server is the one that had the issue with ghost connections. The issue has not returned since my initial post
I would like to run the tests you suggest on our Dev server. However to do this I will need to give that server access to the ODBC source, which requires a third party to work with me. I am expecting to be able to do this in the new year. I will let you know when I have done this, hopefully early in the new year.
Like • Show 0 Likes0
Actions
james_quiggins @ alecgregory on Dec 17, 2018 10:08 AM
Mark Correct
Correct Answer
alecgregory wrote:

Since it's a dev server, could you set your odbc script to run over and over again and see how quickly you can reproduce? Every hour or so just try to login to a database with go then put the phone to sleep. See if the connection gets cleaned up

Maybe try setting up 3 or 4 server side script sessions doing this import every minute.
Unfortunately the ODBC is only on the production server, which is where we saw the ghost connections. To clarify and summarize:

The DevTest server had issues with error 812. This is the server I attached a crash log for, although you determined that this was a crash on shutdown so it is likely not related to the 812 error.
The production server is the one that had the issue with ghost connections. The issue has not returned since my initial post

I would like to run the tests you suggest on our Dev server. However to do this I will need to give that server access to the ODBC source, which requires a third party to work with me. I am expecting to be able to do this in the new year. I will let you know when I have done this, hopefully early in the new year.
If someone has a reproducible case for ghost client issue where the DBEngine Backgrounding thread hangs during a odbc call I would be so gracious. Until now, I see reports of the issue but haven't been able to get steps to reproduce it. If we can get steps, chance are we can get this fixed. FWIW, we thought we had it fixed and I distributed a test build to a customer I work closely with but it doesn't appear that the issue is fixed.

James
Like • Show 0 Likes0
Actions
james_quiggins @ StephenWonfor on Dec 17, 2018 10:11 AM
Mark Correct
Correct Answer
StephenWonfor wrote:

An update. Box 1 has not had ghosts or FMSE quits over the past 4 days. Nothing has been done to it other than monitor it. No ESS connections. The only add-on is 360Works FTPeek (running fine for years) that does a simple FTP routine at 10 minute intervals during business hours. I note that Activity Monitor shows (sometimes) 50-60% memory use during the routine. Other times barely a blip. The system has 16 GB RAM with 2.8 GHz Intel Core i5.
Also ran across this thread about the fmsased.
FMS13 fmsased Memory Leak - fmsased grows until restart when using scheduled scripts
Hi Stephen, Can you post a crash report/dump from the quits? This will give us some insight into whats happening on your box.

James
Like • Show 0 Likes0
Actions

StephenWonfor @ james_quiggins on Dec 28, 2018 3:13 PM

James

Not very deep-tech savvy here. I can report from the FMServer log file things like this.

This is from early thins morning - no users - looks like the FMSE stalls, chokes scripts for a while then heals it self. This is totally unattended. Any other "log files for dummies" that I can access? The script in question just writes a new record into a a log file then sends an eMail - eMail a recent add, this has been going on for months now without that step.

Fri Dec 28 07:30:05 MST 2018	Schedule "H_HourlyStatus" completed.
Fri Dec 28 07:30:00 MST 2018	Schedule "H_HourlyStatus" has started FileMaker script "ServerSide - Write to Script LOG (Hourly)".
Fri Dec 28 07:30:00 MST 2018	Schedule "H_HourlyStatus" running.
Fri Dec 28 06:30:05 MST 2018	Schedule "H_HourlyStatus" completed.
Fri Dec 28 06:30:05 MST 2018	Schedule "H_HourlyStatus" scheduled for 12/28/2018 07:30 AM.
Fri Dec 28 06:30:00 MST 2018	Schedule "H_HourlyStatus" running.
Fri Dec 28 06:30:00 MST 2018	Schedule "H_HourlyStatus" has started FileMaker script "ServerSide - Write to Script LOG (Hourly)".
Fri Dec 28 05:30:03 MST 2018	Schedule "H_HourlyStatus" completed.
Fri Dec 28 05:30:03 MST 2018	Schedule "H_HourlyStatus" scheduled for 12/28/2018 06:30 AM.
Fri Dec 28 05:30:00 MST 2018	Schedule "H_HourlyStatus" running.
Fri Dec 28 05:30:00 MST 2018	Schedule "H_HourlyStatus" has started FileMaker script "ServerSide - Write to Script LOG (Hourly)".
Fri Dec 28 04:30:07 MST 2018	Schedule "H_HourlyStatus" completed.
Fri Dec 28 04:30:07 MST 2018	Schedule "H_HourlyStatus" scheduled for 12/28/2018 05:30 AM.
Fri Dec 28 04:30:00 MST 2018	Schedule "H_HourlyStatus" running.
Fri Dec 28 04:30:00 MST 2018	Schedule "H_HourlyStatus" has started FileMaker script "ServerSide - Write to Script LOG (Hourly)".
Fri Dec 28 03:30:03 MST 2018	Schedule "H_HourlyStatus" aborted; aborted by user.
Fri Dec 28 03:30:03 MST 2018	Schedule "H_HourlyStatus" scheduled for 12/28/2018 04:30 AM.
Fri Dec 28 03:30:03 MST 2018	Schedule "H_HourlyStatus" scripting error (1) at "experimentalfallgroupdatabase : ServerSide - Write to Script LOG (Hourly) : 12 : Set Variable".
Fri Dec 28 03:30:03 MST 2018	Schedule "H_HourlyStatus" scripting error (1) at "experimentalfallgroupdatabase : Sub - RegisterEmail : 5 : Set Variable".
Fri Dec 28 03:30:00 MST 2018	Schedule "H_HourlyStatus" running.
Fri Dec 28 03:30:00 MST 2018	Schedule "H_HourlyStatus" has started FileMaker script "ServerSide - Write to Script LOG (Hourly)".
Fri Dec 28 02:32:00 MST 2018	Schedule "H_HourlyStatus" aborted; time limit exceeded or server stopped.
Fri Dec 28 02:32:00 MST 2018	Schedule "H_HourlyStatus" scheduled for 12/28/2018 03:30 AM.
Fri Dec 28 02:30:00 MST 2018	Schedule "H_HourlyStatus" has started FileMaker script "ServerSide - Write to Script LOG (Hourly)".
Fri Dec 28 02:30:00 MST 2018	Schedule "H_HourlyStatus" running.
Fri Dec 28 01:45:03 MST 2018	Schedule "H_HourlyStatus" scripting error (1) at "experimentalfallgroupdatabase : ServerSide - Write to Script LOG (Hourly) : 12 : Set Variable".
Fri Dec 28 01:45:02 MST 2018	Schedule "H_HourlyStatus" scripting error (1) at "experimentalfallgroupdatabase : Sub - RegisterEmail : 5 : Set Variable".
Fri Dec 28 01:32:00 MST 2018	Schedule "H_HourlyStatus" aborted; time limit exceeded or server stopped.
Fri Dec 28 01:32:00 MST 2018	Schedule "H_HourlyStatus" scheduled for 12/28/2018 02:30 AM.
Fri Dec 28 01:30:00 MST 2018	Schedule "H_HourlyStatus" running.
Fri Dec 28 01:30:00 MST 2018	Schedule "H_HourlyStatus" has started FileMaker script "ServerSide - Write to Script LOG (Hourly)".
Fri Dec 28 01:00:01 MST 2018	Schedule "H_HourlyStatus" scripting error (1) at "experimentalfallgroupdatabase : Sub - RegisterEmail : 5 : Set Variable".
Fri Dec 28 00:32:00 MST 2018	Schedule "H_HourlyStatus" scheduled for 12/28/2018 01:30 AM.
Fri Dec 28 00:32:00 MST 2018	Schedule "H_HourlyStatus" aborted; time limit exceeded or server stopped.
Fri Dec 28 00:30:00 MST 2018	Schedule "H_HourlyStatus" running.
Fri Dec 28 00:30:00 MST 2018	Schedule "H_HourlyStatus" has started FileMaker script "ServerSide - Write to Script LOG (Hourly)".
Thu Dec 27 23:30:05 MST 2018	Schedule "H_HourlyStatus" completed.
Thu Dec 27 23:30:05 MST 2018	Schedule "H_HourlyStatus" scheduled for 12/28/2018 12:30 AM.
Thu Dec 27 23:30:00 MST 2018	Schedule "H_HourlyStatus" running.
Thu Dec 27 23:30:00 MST 2018	Schedule "H_HourlyStatus" has started FileMaker script "ServerSide - Write to Script LOG (Hourly)".
Thu Dec 27 22:30:05 MST 2018	Schedule "H_HourlyStatus" completed.
Thu Dec 27 22:30:05 MST 2018	Schedule "H_HourlyStatus" scheduled for 12/27/2018 11:30 PM.
Thu Dec 27 22:30:00 MST 2018	Schedule "H_HourlyStatus" running.
Thu Dec 27 22:30:00 MST 2018	Schedule "H_HourlyStatus" has started FileMaker script "ServerSide - Write to Script LOG (Hourly)".

Actions

StephenWonfor Feb 12, 2019 10:18 AM
Mark Correct
Correct Answer
Hi
Back on this topic again. I found some info that indicated that the FMSE is very "allergic" to script errors - even the softest of errors. Of any kind. So I went through all 25 serverside routines.
Got rid of the 101 (Record is missing) on GoToNextRecord(ExitAfterLast) by disabling ExitAfterLast and adding an ExitLoopIf Get(FoundCount) = Get(RecordNumber).
Got rid of the 401 (No Records match the request) by the incredibly lame approach of adding a new request to all searches on the server and have that request find a record I know to be there (of course this is fragile, frangible, delicate and bad form but it was worth a shot). So I ensured that my 7 targeted tables each have a record with a recordID = 1. So it always gets found. If FoundCount = 1 is now really 0 and the script behaves as though it was 0. If FoundCount > 1 a little recordID sort and an omit record step.
The FMSE hangs still occur but much less frequently.
I now have a suspect script that shows no errors but seems to be the one that, when the FMSE fails, is the one trying to run.

Film at 11.

Stephen
1 person found this helpful
Like • Show 2 Likes2
Actions

Oh FMSE, oh FMSE, how convoluted are thy behaviours

Outcomes

Attachments

Attachments

Related Content

Recommended Content

Incoming Links