Troubleshooting

• What are "Server Messages" and why do I want them?
• Booster ID Generation
• Enable core dumps for booster crashes

What are "Server Messages" and why do I want them?

What

Perhaps you have seen the option in Superprefs Editor or in Client Monitor about "Route server messages via boosters" and asked yourself what that was?

When/Why

We know that when a client is talking to the FileWave server it does a check-in every so often (2min default). But how does it talk and what is said?

When we take a look at the Default TCP and UDP Port Usage for FileWave we see 20015 and 20017 (communications between client and server). There is also NATS ports that handle notifications for things like initiating a TeamViewer session.

Note: The default port setting is 20015. However, SSL is now required, and the system will automatically use port 20017 instead when 20015 is entered. Do not manually set the port to 20017. Always enter 20015, and the system will handle the SSL port change for you.

How

Basically, server messages are the communications a client needs to work with the server. Below is a list of messages that could be sent via the publishing and routing services if this option is enabled. You should enable Route Server Messages via boosters to let your Boosters handle these additional communications to take burden off the FileWave Server.

• Checkin

• Fileset properties and status

• Software updates

• Lock / Unlock client

• Kiosk categories and item info

Booster ID Generation

Description

In some circumstances, a Booster may appear as missing or multiple boosters may overwrite a single Booster record in the Admin console.  This can occur where each booster is a copy of another booster, e.g. VM source is identical.

Where Booster IDs conflict, it generating a new Booster ID will be necessary

Directions

Running the following command through a Booster shell should force a Booster to configure a new Booster ID.

Linux & macOS

fwcontrol booster stop && rm -f /etc/xdg/FileWave/Booster.conf && rm -f /var/FWBooster/*.key && rm -f /var/FWBooster/*.crt && fwcontrol booster start

It will then be necessary to 'Enroll Booster(s)' from their contextual menu, even if previously enrolled.

 

 

Enable core dumps for booster crashes

For Debian

It is important that you undo this after the issue has been identified.

Step-by-step guide

1. edit this file:
   sudo vi /usr/local/etc/filewave/supervisor/supervisord-booster.conf

2. Uncomment this line:
   command=/bin/bash -c "ulimit -c unlimited && /usr/local/sbin/fwbooster

3. restart the booster:

   sudo /etc/init.d/fw-booster restart

4. edit this file:

   sudo vi /etc/sysctl.conf

5. Add the lines below:

   kernel.core_uses_pid = 1

   kernel.core_pattern = /tmp/core-%e-%s-%u-%g-%p-%t

   fs.suid_dumpable = 2

6. Reload the settings in /etc/sysctl.conf:

   sysctl -p
   

7. Open the limits configuration file:
   sudo vi /etc/security/limits.conf
   

8. Add the following lines to set unlimited core dump sizes for all users:

   * soft core unlimited
   

   * hard core unlimited

9. Save and close the file. Note: Changes take effect upon the next login. You may need to restart the system or re-login for the settings to apply.

For testing purpose:
Kill booster process e.g:
(ps ax | grep fw)
kill -6 3014

Check if a core dump is generated under /tmp.
Should be something like this:
core-fwbooster-6-0-0-8440-1509016449