First, you need to make sure that nginx is working:

service nginx restart
service nginx status #(checking the service status)
nginx -t             #(checking the syntax of files if the service doesn’t start)

An example of the output of responses to commands when the service is working correctly:

nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: en
Active: active (running) since Tue 2021-08-03 13:46:09 MSK; 2min 56s ago

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

If there are syntax errors in the nginx configuration or nginx doesn’t work, you should solve the problem at the level of specialists who maintain the server.

In such a situation, you should:

1. Check if there is an "install" folder in the /home/wialon/wlocal directory.
   If there is no such folder, the Wialon Local installation likely failed. If the folder exists, try to restart the Wialon Local process:

   service wlocal restart

2. Try to reinstall Wialon Local from the ISO image, following all the necessary requirements:
   • You should carry out the installation in the BIOS mode, and for UEFI — in the Legacy mode;
   • When installing the OS, you cannot skip the step with specifying the network connection settings;
   • There should be no other network restrictions on the server that don’t allow downloading the appropriate packages for service operation.

If the result has not changed after reinstalling Wialon Local, please contact support@gurtam.com to install the service manually.

Check:

ps aux | grep -v grep | grep node
top | grep wialon

An example of the expected list of active processes from the first command in a working service:

wialon 701 0.0 2.3 591208 47884 ? Ssl 12:27 0:00 /usr/bin/node /usr/lib/node_modules/forever/bin/monitor cron.js
wialon 713 1.3 36.4 1491260 745596 ? Sl 12:27 0:49 /usr/bin/node /home/wialon/wlocal/cron.js

If an empty response is received for the specified commands or the cron.js process from the first command is missing, the Wialon Local processes are not running. Try to start the service again:

service wlocal restart
service wlocal status #(checking the start)

If the service cannot start, you should:

1. Check the version of packages required for Wialon Local operation using the following commands

   node -v 
   nodejs -v
   npm -v
   npm -g list | grep forever

   Responses to the first two commands must meet the Wialon Local version requirements specified in the documentation:

   Wialon Local versions	Debian versions	Node.js versions
   1504, 1604, 1704	8 (Jessie)	0.10.x
   1704, 1804, 1904	9 (Stretch)	6.x
   1904, 2004, 2104	10 (Buster)	10.x

   If the Node.js version doesn’t match the required version, you should update it.
   An empty response to the third and/or fourth command means there is no npm package and its forever module. To install them, consult the instructions in the documentation (2004/2104 and 1704/1804/1904).

2. Analyze the Wialon Local service logs in /home/wialon/wlocal/logs/lcm/ and, if there are errors related to Node.js, reinstall the Wialon Local components required for correct operation, according to the documentation. An example of similar errors:

   Error: Most middleware (like json) is no longer bundled with Express and must be installed separately ...

   Look carefully at the output of the installation results to avoid overlooking errors that may occur during the update.

If the administration system is still unavailable after the steps taken, please write to support@gurtam.com.

This can happen when you execute a report that uses road speed limits related to Gurtam Maps. In this case, you should check if you have the necessary access to Gurtam Maps resources: lic.gurtam.com 18611-18614

If you use other maps (Yandex, Google), you should open appropriate access to their servers.

Requirements for Fleetrun and Nimbus operation in Wialon Local are described in the documentation:

• Availability of a separate DNS;
• Availability of a flespi token in the admin panel;
• A corresponding service is activated in the account;
• Full chain of SSL certificates for DNS that is used for the application (the application must work over HTTPS);
• For Nimbus: availability of connected Gurtam Maps;
• Direct access to:

  apps.wialon.com 80/443
  mqtt.flespi.io  8883 (SSL) or 1883 (non-SSL)

If all requirements are met, but the app authorization issue remains, please contact support@gurtam.com.

First of all, you should check if there are any network limitations between the backup and main servers, and conduct a basic check of the backup server availability over the standard 32001 port, for example, via telnet from the main Wialon Local server:

telnet <backup_server_address> 32001 

In this case, the 32001 port is the standard port specified in the administration system of the main server. This port is used for subsequent data synchronization. It can be changed, so carefully check if the corresponding ports are available on the backup and main servers between which you’ve set synchronization.

You should also analyze the backup module logs in the /home/wl_storage_backup/logs/trace.log file for errors. Particularly, logs may contain errors of the following type:

2021/05/24 17:19:50:007: [INF:73907700] net_session::bg_task(2167042, '192.168.0.15:32001'): pipe not connected
2021/05/24 17:19:50:007: [INF:4CA1E700] messages_sync_server::sync_thread('192.168.0.15:32001:******'): invalid reply from synchronization server

Such errors indicate the access issues between servers.

If the backup server is unavailable for a long time, or if the synchronization cache files take up too much disk space, you should stop the backup module on the backup server using the command:

service wlbackup stop

After that, you need to solve the access issues between servers and delete the backup copy of the database in the /home/wl_storage_backup/storage directory.

Next, stop the Wialon service in the main server administration system, then execute the "service wlocal stop" command to stop the administration system site, and only then delete the critically overflowed synchronization cache files, for example, by using the command:

find /home/wialon/wlocal/storage -name sync.cache.* -type f -delete

When manually deleting the synchronization cache files, keep in mind that the necessary files are located in different folders of the /home/wialon/wlocal/storage directory and have names in the following format: sync.cache.1983335884, where numbers at the end may change.

After completing all the procedures, the synchronization process is launched in two stages: first, Wialon Local is enabled on the main server, then on the backup one. To do this, use the following commands:

On the main:
service wlocal start

On the backup:
service wlbackup start

A "sync finished" entry in the /home/wialon/wlocal/logs/trace.log file indicates the end of the synchronization process on the backup server. Also, for additional verification, you can compare the statistics on messages on the main server in the /home/wialon/wlocal/storage/ms/msgs_stats.txt file and on the backup server in the /home/wl_storage_backup/storage/ms/msgs_stats.txt file — with complete synchronization, the numbers must correspond.

Examples of logs:

2021/07/16 15:50:52:031: [INF:C2B98700] Can`t connect to SMPP server
2021/07/16 15:51:06:558: [INF:C2B98700] Can`t connect to SMPP server
2021/07/16 15:52:12:289: [INF:C2B98700] Can`t connect to SMPP server

2021/07/16 15:51:06:556: [INF:C2B98700] avl_gsm_device::begin_comm('Testing', 'd7d1eeb6c3361727b848012bf5a540d0'): 0
2021/07/16 15:51:06:558: [INF:C2B98700] Can`t connect to SMPP server

2021/07/16 15:55:16:332: [INF:C2B98700] avl_gsm_device::begin_comm('Testing', 'd7d1eeb6c3361727b848012bf5a540d0'): 0
2021/07/16 15:55:16:332: [INF:C2B98700] remote_gsm_device::start(88)

And no more messages of communication with the modem.

2021/07/16 15:56:23:400: [INF:AADC7700] avl_gsm_device::begin_comm('Testing', 'd7d1eeb6c3361727b848012bf5a540d0'): 0

And no more messages of communication with the modem.

To diagnose the connection, always check the availability of a remote host or gateway and also that the modem is mounted at the address indicated in the admin panel and responds to commands (for example, via minicom).

If SMS messages are sent from the Wialon service but don’t reach the final destination according to logs, you should solve the problem on the recipient’s side or the modem side. If there is no connection to the modem or remote gateway, you should do the same: such issues should be addressed at your network, modem, or gateway level. In any other situation, please contact support@gurtam.com.

Transfer (migration) process of the Wialon Local service should be performed in the order described below:

1. Inform your personal manager about the date of transfer.

2. Deploy Wialon Local on the new server from ISO image, strictly following the official instructions up to step 5 inclusive (i.e., do not log in to the admin panel).
   
3. Stop the Wialon service in the administration system of the old server, and then execute the "service wlocal stop" command to stop the site of the administration system itself.
4. Log in to the administration system of the new server, wait for the installation of the main modules required for Wialon Local operation.
5. Start Wialon on the new server and make sure it works stably.
6. Stop the Wialon service in the administration system of the new server, and then execute the "service wlocal stop" command to stop the administration system site.
7. Copy the contents of the /home/wialon/wlocal/storage directory from the old server to the new one into the same directory. Previously, delete the contents of the /storage directory on the new server.
8. Start the Wialon Local service again (the service wlocal start command) and Wialon in the administration system on the new server to make sure that the database substitution was successful and the service works correctly.

If the backup module from the Wialon Local ISO image has already been installed on the server intended for the migration, then the migration instructions are the same as in the case of using the backup server as the main one. The procedure is described in the documentation.

First of all, if you are using a backup server, you should check your backup database files on the backup server in the /home/wl_storage_backup/storage/md and home/wl_storage_backup/storage/pd directories using the db_verfify script, which should be created in the /home/wialon/wlocal directory. Its contents are shown below. The script must be executed strictly from this very directory (home/wialon/wlocal) using the ./db_verify.sh command.

#! /bin/sh
export PATH="./modules/adf/bin:./modules/dep/bin:$PATH"
export LD_LIBRARY_PATH="./modules/adf/lib:./modules/dep/lib:$LD_LIBRARY_PATH"
export ADF_SCRIPT_PATH="modules/adf_scripts/scripts"
export TCL_LIBRARY="./modules/dep/lib/tcl8.4"
ulimit -c 0
db_verify /home/wialon/wlocal/storage/pd/*.db
db_verify /home/wialon/wlocal/storage/md/*.db

If you suppose that some specific db-files were damaged, you can substitute the name of a specific database file instead of *.db in the last line, for example, m-00000001.db. Then the line will look like this:

db_verify /home/wialon/wlocal/storage/md/m-00000001.db

An example of the result of script execution:

Successful verification:
BDB5105 Verification of /home/wialon/wlocal/storage/md/m-00000001.db succeeded.
BDB5105 Verification of /home/wialon/wlocal/storage/md/m-00000002.db succeeded.
BDB5105 Verification of /home/wialon/wlocal/storage/md/m-00000003.db succeeded.

DB file verification failed:
BDB5105 Verification of /home/wialon/wlocal/storage/md/m-00000003.db failed.
BDB5105 Verification of /home/wialon/wlocal/storage/md/m-00000004.db failed.

If no errors are found as a result of verification, you have 2 options:

1. Before performing any manipulations with database substitution, you should stop Wialon in the administration system on the main server and the Wialon Local service itself (service wlocal stop), and also stop the backup service on the backup server (service wlbackup stop). After that, replace the database on the main server (the /home/wialon/wlocal/storage directory), the database on the backup server (the /home/wl_storage_backup/storage directory) and start Wialon.
2. Use the backup server as the main one according to the Restoring from Failure instructions.

If the db files on the backup server are also damaged, try to delete the backup database and restart the synchronization process. As soon as it finishes, check the copied database using the db_verify script and, if successful, you can substitute it on the main server. The database should be substituted from the /home/wl_storage_backup directory on the backup server instead of the /home/wialon/wlocal/storage directory on the main one. At the same time, it’s recommended to save the damaged database of the main server in a separate location and not delete it until you can start Wialon without errors.

If the solution with using the backup server didn’t work, you can try to use standard utilities to restore separate files manually. We also recommend that you run the db_verify script again and localize all broken db files before further actions. Let's consider this option using the /home/wialon/wlocal/storage/md/m-00000007.db file as an example (if there are other damaged files, you should do the same).

Stop the Wialon service in the administration system, and then execute the "service wlocal stop" command to stop the administration system site. After that, run the following commands in the /home/wialon/wlocal directory:

export PATH="./modules/adf/bin:./modules/dep/bin:$PATH"
export LD_LIBRARY_PATH="./modules/adf/lib:./modules/dep/lib:$LD_LIBRARY_PATH"
export ADF_SCRIPT_PATH="modules/adf_scripts/scripts"
export TCL_LIBRARY="./modules/dep/lib/tcl8.4"
ulimit -c 0

After that, you can start the database manipulations (scripts below are already in Wialon, and you just need to execute them in the /home/wialon/wlocal directory):

db_dump -r /home/wialon/wlocal/storage/md/m-00000007.db | db_load /home/wialon/wlocal/storage/md/m-00000007.db.new

Then, in the /home/wialon/wlocal/storage/md directory, rename the new and old database file using the following commands:

 mv m-00000007.db m-00000007.db.old

 mv m-00000007.db.new m-00000007.db

These are standard database utilities that will re-create your db file.

Next, start Wialon and check trace.log for errors. Then run the m-00000007.db file and other broken files again through the db_verify script when the service is stopped.

If none of the above recommendations helped you, write to support@gurtam.com and describe all the actions you performed, as well as the issues you encountered while restoring the database files.