Are you experiencing unexpected restarts of your FileMaker Server service while on Ubuntu? Maybe you return to work finding your database(s) closed for no apparent reason?!?! There is [hopefully] a good explanation for this. It is very possible your system is performing unattended maintenance. We can check for this potential cause easy enough, and then consider configuration changes that fit your organization requirements.
Database Alarms in the Middle of the Night 😱
Diagnosis
In our example case, administrators have decided to disable the automatic opening of databases during FMS startup. There are a few good reasons for this we will not cover here. It might also be that databases are protected with Encryption At Rest, requiring an operator to be present for databases to be opened after a restart, also good reasons for this.
First check the logs to see if there are recent notices of a graceful FileMaker shutdown which coincide with apt upgrades.
grep -e apt-daily-upgrade.service -e fmshelper.service /var/log/syslog
Search the latest system log file for any lines that mention either of the services of interest here.
... 2025-08-14T06:55:47.163937+00:00 blue systemd[1]: Starting apt-daily-upgrade.service - Daily apt upgrade and clean activities... 2025-08-14T06:55:50.578429+00:00 blue systemd[1]: Stopping fmshelper.service - FileMaker Server Service... 2025-08-14T06:56:08.836919+00:00 blue systemd[1]: fmshelper.service: Deactivated successfully. 2025-08-14T06:56:08.837799+00:00 blue systemd[1]: Stopped fmshelper.service - FileMaker Server Service. 2025-08-14T06:56:08.837939+00:00 blue systemd[1]: fmshelper.service: Consumed 1h 32min 8.692s CPU time, 961.5M memory peak, 484.8M memory swap peak. 2025-08-14T06:56:08.846175+00:00 blue systemd[1]: Starting fmshelper.service - FileMaker Server Service... 2025-08-14T06:56:11.596493+00:00 blue systemd[1]: Started fmshelper.service - FileMaker Server Service. 2025-08-14T06:56:13.510502+00:00 blue systemd[1]: apt-daily-upgrade.service: Deactivated successfully. 2025-08-14T06:56:13.511519+00:00 blue systemd[1]: Finished apt-daily-upgrade.service - Daily apt upgrade and clean activities. 2025-08-14T06:56:13.511879+00:00 blue systemd[1]: apt-daily-upgrade.service: Consumed 5.083s CPU time. ...
Here we can see that during a brief timeframe: the apt-daily-upgrade started, fmshelper was stopped, started, and then apt-daily-upgrade finished. This seems to be a clear correlation.
Background
Ubuntu uses a combination of automated services to keep systems up to date. The default behavior of these systems continues to evolve over time to improve both security and convenience. The apt package manager has some scheduled services for both downloading and applying upgrades. Let’s check on these:
systemctl status apt-daily.timer
● apt-daily.timer - Daily apt download activities
Loaded: loaded (/usr/lib/systemd/system/apt-daily.timer; enabled; preset: enabled)
Active: active (waiting) since Wed 2025-07-30 19:49:55 UTC; 2 weeks 1 day ago
Trigger: Fri 2025-08-15 06:40:58 UTC; 8h left
Triggers: ● apt-daily.service
Jul 30 19:49:55 blue systemd[1]: Started apt-daily.timer - Daily apt download activities.
systemctl status apt-daily-upgrade.timer
● apt-daily-upgrade.timer - Daily apt upgrade and clean activities
Loaded: loaded (/usr/lib/systemd/system/apt-daily-upgrade.timer; enabled; preset: enabled)
Active: active (waiting) since Wed 2025-07-30 19:49:55 UTC; 2 weeks 1 day ago
Trigger: Fri 2025-08-15 06:36:10 UTC; 8h left
Triggers: ● apt-daily-upgrade.service
Jul 30 19:49:55 blue systemd[1]: Started apt-daily-upgrade.timer - Daily apt upgrade and clean activities.
When upgrades are completed, another utility needrestart is invoked. It’s job is to scan for, report, and potentially act on services to restart, that have been affected by newly installed updates. This is a good thing. For example, a security vulnerability might be discovered in a core Ubuntu package. The system may automatically install the needed upgrade and restart the package. Furthermore, if FileMaker server depends on that libraries provided by that package, it is possible that the FileMaker server remains vulnerable until it is also restarted, in order to load using the latest libraries.
If you are manually running apt to install or upgrade packages, there is a good chance you may have already seen a window like this.
Notice there are two services showing here, which appear to be using outdated libraries. The recommended and default action is to restart them both. If you press the enter key without careful consideration, your FileMaker databases will be closed and the engine restarted. Alternatively you can uncheck fmshelper or choose cancel if this isn’t a convenient time to restart the database engine.
If the kernel has been replaced, there is a related prompt recommending a full restart, but this step is left in the hands of the administrator.
New in Ubuntu 24
Ubuntu 22 would not automatically restart dependent services during the nightly (noninteractive) upgrade process. Instead it would just output a list of services that should be restarted. Ubuntu 24.04 changed this. Now when a noninteractive script calls the needrestart utility, it will automatically restart the dependent services. Ouch!
This doesn’t mean a nightly restart of the FileMaker server process, but any time a package is upgraded which could have a downstream library impact on any FileMaker, it will in fact be restarted.
Fix
You will probably find several sledgehammer approaches to combat these default behaviors. I’ll mention them here, but I would NOT generally recommend them:
- globally alter the needrestart configuration to only notify, defer all service restarts
- completely remove the needrestart package
- disable or remove unattended upgrades related to the apt system
Any of these suggestions regress to former, though familiar, approaches to maintenance and generally result in less security for your system.
In our case, we’ve elected to defer automatic service restarts just for FileMaker related services. Allowing other Ubuntu and 3rd party services to continue with their updates and restarts will help to keep them secure. Arguably we are making FileMaker server a little less secure, but in exchange for an uptime improvement for users that depend on our server remaining available, with encrypted databases open. This will leave the responsibility on us to periodically restart the FileMaker server with a frequency determined by our security an operational requirements.
The needrestart utility already has a configured list of services that can cause problems if automatically restarted. We follow this pattern to defer restarts for services that match the FileMaker specific names.
echo '$nrconf{override_rc}{qr(^fmshelper\.service$)} = 0;' | sudo tee /etc/needrestart/conf.d/fmshelper.conf
Augment needrestart configuration for services matching fmshelper.service
echo '$nrconf{override_rc}{qr(^com\.filemaker\.)} = 0;' | sudo tee /etc/needrestart/conf.d/com.filemaker.conf
Augment needrestart configuration for services starting with com.filemaker.
After these commands, feel free to examine the files created under /etc/needrestart/conf.d/. Simply remove those files if you want to revert this change.
Test
If a pending FileMaker restart is needed right now, you can verify that the restart will be deferred.
sudo needrestart -l -r l
Check for issues related to obsolete libraries, only listing the prescribed action.
Scanning processes...
Scanning candidates...
Services to be restarted:
systemctl restart packagekit.service
Service restarts being deferred:
systemctl restart fmshelper.service
No containers need to be restarted.
No user sessions are running outdated binaries.
No VM guests are running outdated hypervisor (qemu) binaries on this host.
Now test again via the interactive ascii interface.
sudo needrestart -l -r i
Check for issues related to obsolete libraries, using the interactive menu showing prescribed actions.
Notice that the fmshelper.service is now unchecked by default.
