Other apps
Wialon for Android/iOS
Wialon Local
Wialon Hosting
en ru es
By date
Wialon Local Administrator Memo
  • technical_consulting
  • administration_system
  • installation
  • upgrading_wialon_local
  • backup
  • logs
  • license

This memo was created for the convenience of Wialon Local administrator. We tried to gather here a brief list of the necessary accesses, peculiarity of some standard procedures (disk space control, working with logs and backups), as well as prohibited actions during the work and maintenance of Wialon Local.



  • lic.gurtam.com 31176 — license components check.

  • local-api.wialon.com 443 — scripts’ and modules’ updates.


  • lic.gurtam.com 18711 — Wialon LBS service.

  • lic.gurtam.com 18712 — Wialon mobile push notifications service.

  • lic.gurtam.com 18611-18616 — Gurtam Maps service.

  • https://distro.gurtam.com/maps/ — the old AVD maps storage.

  • https://api.telegram.org — Telegram notifications service.

  • https://acme-v02.api.letsencrypt.org/ — Let's Encrypt auto certificates (mandatory require the port 80 to be opened).


  • mqtt.flespi.io 8883 (SSL) or 1883 (not SSL) — MQTT broker.

  • app-local.wialon.com port 443 — to access NimBus, Fleetrun, Hecterra, Logistics, and other Wialon-based apps.

  • apps-svcs.wialon.com port 443 — to access app Dashboard.


Default port range for Wialon hardware in iptables:

  • -A INPUT -p udp -m state --state NEW -m udp --dport 20100:30000 -j ACCEPT

  • -A INPUT -p tcp -m state --state NEW -m tcp --dport 20100:30000 -j ACCEPT

Video server

  • Port 1935 or 19350 depending on the device type.

  • Port 8083 — to get files from the video server.


  • BASE URL for Logistics, Nimbus, Fleetrun, Hecterra should be an external DNS record.
  • The connection URL for the Wialon Local mobile app should be external without the port. Access through IP:port is not applicable.
  • The Let’s Encrypt certificates generation and updating are performed through the HTTP request, port 80. The attempt to auto update the certificate takes place a month before its expiration date. If failed, the next attempt takes place again in a week.

Storage space control

  • Wialon Local is installed to /home/wialon/wlocal by default.

  • Wialon controls the free space in /home only, if there’s less than 5Gb left in /home/, the Wialon service stops automatically to prevent the database from being damaged.
  • The database files defragmentation is done automatically, if the degree of fragmentation exceeds 20%. There should be 2,5 times more space than the database file size to finish defragmentation successfully. The current level (or percentage) of the database files fragmentation can be viewed in the wlocal/storage/ms/msgs_stats.
  • Logrotate stores and rotates logs for the last 10 days by default. Check the logs rotation failures from time to time.
  • There can be cache files for sending data to the backup server in wlocal/storage, wlocal/storage/md and wlocal/storage/pd. They have names like sync.cache.. The cache files’ size of more than 1Gb indicates the network’s slow speed, the backup server being unavailable, or that the hot backup was stopped.
  • The file with cache of the received messages for the database may be created in /home/wialon/wlocal/ with the extension *.msgs. The cache size of more than 1Gb causes the slow writing speed, the slow disk work, and might indicate the database/disk damage.
  • For the system to function normally and for the authorization in the administration panel, there should always be free space in /root/ and /var/.

Folders and logs

  • All the Wialon Local logs are located in /home/wialon/wlocal/logs/ by default. They are stored and rotated for the last 10 days (logrotate).

  • The SMS sending via the SMPP gateway or GSM modem is logged in trace.log of the Wialon service. The communications with the gateway or GSM device and the SMS sending are logged in smpp_device_*, gsm_device_*.
  • The email sending via the MAIL server is logged in trace.log. You should analyze the processing and sending of the email by the MAIL server logs (postfix/mailx by default, or directly SMTP logs). The timeout for the command sending to the SMTP server in Wialon is 10 sec. The timeout for getting a response (code 250) from the SMTP server in Wialon is 5 sec. There are 5 attempts to get an email to be sent by Wialon -> SMTP. After the fifth unsuccessful attempt, the task for the email sending is removed from the queue. The email sending errors are recorded in trace.log.
  • The issues with Let’s Encrypt certificates generation and updating are logged in lcm/lcm.log. Sometimes instead of the certificate renewal, it’s better to delete old SSL certificates (click the Default button) and generate new ones.
  • All entries from the service logs with the word "error" get to error.log. It means that such entries are not always actual errors. For example, it can be word "error" in the tracker’s response to the command, or word "error" in the name or the text of the executed report/notification.
  • Text files with the statistics for the charts of the administration panel resources are stored in /home/wialon/wlocal/tmp/charts/. These files are not rotated or deleted. If needed, the old files can be deleted manually after stopping Wialon Local.
  • When Wialon Local fails, the system attempts to make the automatic dump of the Wialon process. The dump files are stored in the folder debug/.
  • The downloaded video files from the trackers has MP4 format and are stored separately from the Wialon DB in /mnt/storage/video. This folder is created when the video service is installed.
  • The error.log and admin's email notification trigger on any activity in trace.log with the key words 'error' and 'PANIC'. It is recommended to avoid these words and the key match as a part of other words in the system items' names (units, reports, notifications) to prevent the false error/PANIC email warnings to admin.

Hot backup

  • An automatic control of the free space on the disk is not available, so it’s crucial to monitor the disk overflow with in-built tools.
  • Primary synchronization of the database ends with the entry "Sync finished" entry in trace.log.
  • When the connection is lost or there are internet/network issues, the "pipe_not_connected" entry appears in trace.log.
  • The growth of the synchronization cache on the main server, with the backup module configured and working, mainly indicates about insufficient data transfer speed over the network, insufficient read-write speed of disks, synchronization problems due to a damaged database file or bad disk sectors.

Conditions for forced database synchronization anew:

  • Invalid backup stop. Then the files serial.dat and props.dat, which are responsible for continuing the database synchronization, are not created on the backup.
  • If the backup module or main service was restarted before full synchronization.
  • An error occurred while synchronizing a file (usually due to its corruption).

The list of don’ts when working with and supporting Wialon Local

  • As per the license contract, the interference of the Wialon Local distribution package (changing of any files in any directories) by the client is not allowed. The Wialon configuration changes — website design, SSL certificates, Wialon service limitations, etc. — are performed through the administration system.
  • Two and more Wialon services are prohibited to be launched simultaneously on one license.
  • The server shutdown and the OS restart are prohibited when the Wialon service is working.
  • It is forbidden to move or delete the folders and files in the working directory wlocal/ (especially the folder storage/).

Sergey Novikov,Customer Service Engineer

Wialon Local Architecture
  • technical_consulting
  • administration_system

This scheme shows general components of Wialon Local and the interaction between them. It can be useful for system administrators for a basic understanding of Wialon Local architecture, and can also be used for participating in tenders.

Sergey Novikov,Customer Service Engineer

Possible Issues with Wialon Local
  • technical_consulting
  • administration_system
  • sms
  • backup

Wialon Local is a server product, and to use it successfully, you need not only knowledge of Wialon algorithms but also the work of a server administrator. In this article, we’ve compiled the most common issues that Wialon Local server administrators have to address, as well as the instructions for solving them.

All actions described below should be performed by a qualified Linux server specialist. For your convenience, we’ve compiled a list of administering tasks in the user guide.

Administration system errors

When logging in to the administration system, you may encounter various errors. Based on the error code and name, choose one of the following solutions.

The site can't be reached / Unable to connect / Page not found

The site unavailability and the output of errors with such text may be related to the state of nginx.


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.

404 Not Found

If the administration system is unavailable and returns the "404 Not Found" error, it’s most probably that the Wialon Local service was installed incorrectly, and the files needed for the service operation are simply missing.


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@wialon.com to install the service manually.

502 Bad Gateway

The "502 Bad Gateway" error when accessing the administration system may be related to the status of processes connected with Wialon Local operation.



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 versionsDebian versionsNode.js versions
    1504, 1604, 17048 (Jessie)0.10.x
    1704, 1804, 19049 (Stretch)6.x
    1904, 2004, 210410 (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.

  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@wialon.com.

The "502 Bad Gateway" error while executing the report

If you were redirected to a page with a "502 Bad Gateway" error when executing a report in Wialon, or it is observed in the browser console when executing a report, it’s most probably the requested report is trying to download resources to which you have limited access.


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.

Fleetrun/Nimbus authorization issues

If you cannot log in to Fleetrun or Nimbus applications using the password you have for the wialon user, but at the same time you can log in to the monitoring site, you should check whether the application requirements are met.


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@wialon.com.

Increase of the sync cache size

When using the Wialon Local backup module, you may encounter a serious increase in the synchronization cache files with the backup server, which can result in the disk space overflow on the main server. An example of such a file name: /home/wialon/wlocal/storage/md/sync.cache.1983335884. This often occurs due to network problems between the main and backup servers, differences in the speed of data recording to disks, or because the communication channel speed is not enough to transfer the incoming data volume.


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  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, ''): pipe not connected
2021/05/24 17:19:50:007: [INF:4CA1E700] messages_sync_server::sync_thread('******'): 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.

Checking the modem connection to Wialon Local

In case of any difficulties with connecting the modem to Wialon Local, you should analyze logs in /home/wialon/wlocal/logs

SMS transmission to be sent via an SMPP gateway or a GSM modem is logged in trace.log of the Wialon service. Communication with the gateway or GSM device, as well as SMS sending, is logged in /home/wialon/wlocal/logs/ with the smpp_device_* / gsm_device_* names.


Examples of logs:

 SMPP gateway

After creating and enabling the SMPP gateway, a separate smpp_device _*.log file is created, in which all connection errors are recorded, and the fact of connection is logged.
All interactions with the gateway will also be displayed in trace.log.

For example, if there is no connection to the SMPP gateway, the specified logs will contain messages of the following format:

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
 GSM/Network modems

Interaction with GSM and network modems will be recorded only in trace.log until the first connection is established.
An example of entries in the log when there is no connection to the modem:

GSM trace.log
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.
Network trace.log
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@wialon.com.

Transferring Wialon Local to a new server

This can become necessary if there is no backup module at the moment of transition to another physical server. By following the instructions below, you will avoid issues with such a transition.


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. After the transfer, execute the following command on the new server:

    chown -R wialon:wialon /home/wialon/
  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.

Corrupted database files

If Wialon cannot start after an emergency stopping or a server crash, referring to corrupted database files, you can see the following entry in the trace.log file:

2021/08/17 12:50:26:649: [INF:FAB26740] storage_service_db::open_databases: opening database environment...
2021/08/17 12:50:26:713: [INF:FAB26740] storage_service_db::open_databases: opening databases...
2021/08/17 12:50:26:714: [INF:FAB26740] storage_messages_env::open_environment: opening database environment (cache: size: 12104 MB, chunks: 1)...
2021/08/17 12:50:28:049: [INF:FAB26740] storage_messages_env::open_environment: recovering environment: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery
2021/08/17 12:50:28:841: [INF:FAB26740] adf_load_plugin('storage_server'). Error loading plugin. Error initializing storage subsystem as server.
2021/08/17 12:50:28:841: [INF:FAB26740] Error: couldn`t load ADF plugin: 'storage_server'.

If the Wialon service continues to work, and the log contains the "Fatal error, run database recovery" entry, you should immediately stop Wialon (the service and the administration system site) and start recovery procedures.

 Solution 1

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.

 Solution 2

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@wialon.com and describe all the actions you performed, as well as the issues you encountered while restoring the database files.

Mail delivery issues

You may face a situation when emails from Wialon do not reach the recipients. Such an issue may occur in some of the services. For example, sending emails works only from the Wialon Local administration system but not from Wialon itself.

There are two mechanisms for sending email notifications in Wialon Local. Knowing their characteristics can help diagnose potential issues.

 Sending emails from the administration system

Notifications from the administration system are delivered to the administrator's mail specified in the settings (see the Mail system section on the System tab). They operate on the following priority:

  1. Sending emails using the SMTP server specified in the administration system;
  2. Sending emails via postfix if the SMTP settings are not set or if the email cannot be transmitted to the specified mail gateway.

Logs indicating the method and status of sending are located in the /home/wialon/wlocal/logs/lcm.log.* file.

When using your own SMTP server, the send logs should be analyzed on the side of the SMTP itself where it is deployed. In the case of using postfix, the logs can be viewed in /var/mail/ or /var/log/mail.log.*

It should also be noted that Wialon Local supports the use of other mail services besides postfix since the request to send an email is sent to localhost. Thus, if you decide, for example, to use exim instead of postfix, you should make sure that it can handle all incoming mail requests from the server's localhost address.

Starting with Wialon Local 2104, you specify not only the login for authorization in your mail gateway but also the sender's name in the Login field for SMTP server settings in the administration system. If only the Login field is filled out of all the SMTP server settings, then the request to send the email will go to postfix under the specified login. If postifix does not have a user with such a login, then the email will not be sent. Therefore, if you do not use your own SMTP server, then we recommend that you leave all the fields related to it empty.

 Sending emails from Wialon

Emails that are sent when jobs and notifications are completed operate on the following priority:

  1. Sending using the SMTP server specified in the billing plan (please note that the address of the SMTP server in the billing plan should be indicated along with the protocol, for example, "smtps://smtp.gmail.com");
  2. If SMTP is not set in the billing plan, then the email will be sent using the SMTP specified in the administration system;
  3. If none of the SMTP addresses is specified, the email will be sent via postfix.

The main difference from the previous mechanism is that if an email cannot be sent using one of the specified SMTP addresses, then it will not be further transmitted to another SMTP address or to postfix and such an email will simply not be sent in the end. If the email sending fails, you need to make the necessary adjustments to be able to keep using the desired email tool.

Logs of the service the message was sent to as well as its sending status can be found in the /home/wialon/wlocal/logs/trace.log file using the "email" filter. See the final logs of sending via the SMTP server directly at the SMTP server. Find the logs of sending via postfix at /var/mail/ or /var/log/mail.log.*

Following this mechanism, it is also possible to use your own mail service instead of postfix if it is similarly bound to the server's localhost address.

Troubleshooting and configuration of sending mail via SMTP or postfix should be handled by the technical specialist who maintains the Wialon Local server. Our technical support does not include diagnostics and mail system configuration services.

High RAM usage

When working with Wialon Local, you may notice that the service constantly consumes almost all the amount of RAM available on the server. This practice is quite expected, since the Wialon service caches almost all the available RAM, but actively uses only some of it.


Wialon Local caches almost all the available RAM for its work regardless of the amount on the server. The Wialon service caches all RAM for processing requests and tasks, for quick access to pages, and to avoid possible delays and issues associated with access denials due to RAM being used by other applications on the server. Cached RAM is managed by a load balancer that redistributes cached RAM to WIalon or other applications on the server, but the priority is given to Wialon by default.

You can control the use of memory in the administration system on the RAM chart. By hovering over each section of the chart, you can see a record of how much memory is currently actively used and how much is cached.

If there is not enough RAM for the correct operation of the Wialon service, check out the /home/wialon/wlocal/logs/trace.log file to see the following entries:

2022/02/07 01:37:25:092: [INF:2A1BA700] binary_data_writer::allocate_block: error reallocating memory of size 16777216
2022/02/07 01:37:25:092: [INF:2A1BA700] binary_data_writer::allocate_block: error reallocating memory of size 16777216
2022/02/07 01:37:25:092: [INF:2A1BA700] binary_data_writer::allocate_block: error reallocating memory of size 16777216
2022/02/07 01:37:25:092: [INF:2A1BA700] binary_data_writer::allocate_block: error reallocating memory of size 16777216

In such cases, you should check if the server meets the system requirements for the available number of objects. You should also check for the presence of services or applications that could be actively using RAM on the server at the time such an entry appeared and analyze the situation.

nginx configuration issues

All Wialon Local service websites operate using the nginx web server. Sometimes when updating or reinstalling the nginx web server, websites are no longer available for one reason or another. In such cases, you should return to the initial nginx configuration that was on the server after installation from the official Wialon Local image.


When installing Wialon Local from the official image, configuration files for websites are automatically created on the server. Sometimes they have to be edited due to the technical requirements of the server. All responsibility for configuring and setting nginx up lies strictly on the technical specialists who maintain the Wialon Local server.

For further work, it helps to understand what configuration files and settings are present on the server immediately after installing Wialon Local. All the necessary configuration files will be located in the /etc/nginx/conf.d/ directory and their standard appearance after installation is described below.

  1. lcm.conf is the administration system configuration file.

    server {
            listen          80;
            server_name     ;
            client_max_body_size 10000m;
            proxy_read_timeout 500;
            location /50x.html {
                    root /home/wialon/wlocal/nginx/www/nginx-default;
            location / {
                    if ( $args ~* dns-test ) {
                            echo 1;
                    proxy_set_header Upgrade $http_upgrade;
                    proxy_set_header Connection "Upgrade";
                    proxy_pass         http://localhost:8080;
            access_log /var/log/nginx/lcm.access.log;
  2. cms.conf is the temporary CMS Manager configuration file.

    server {
             listen 8024;
             server_name ;
             proxy_set_header Host your.cms_manager.DNS.0:8024;
             proxy_set_header X-Forwarded-For $remote_addr;
             client_max_body_size 64m;
             access_log /var/log/nginx/wdc.access.log;
             location /50x.html {
                     root /home/wialon/wlocal/nginx/www/nginx-default;
             location / {
                     proxy_pass http://localhost:8022;
  3. webmonitor.conf is the temporary Wialon Web configuration file.

    server {
             listen 8025;
             server_name ;
             proxy_set_header Host your.wialon_web.DNS.0:8025;
             proxy_set_header X-Forwarded-For $remote_addr;
             client_max_body_size 64m;
             access_log /var/log/nginx/wdc.access.log;
             location /50x.html {
                     root /home/wialon/wlocal/nginx/www/nginx-default;
             location / {
                     proxy_pass http://localhost:8022;
  4. local.conf is the main configuration file that reflects all the settings of the sites specified in the administration system.
    This file is a symbolic link to the file that is automatically generated based on the websites’ settings in the administration system and is located at /home/wialon/wlocal/nginx/conf/local.conf.

    This configuration file is strictly forbidden to edit, we also do not recommend unlinking the symbolic link. All the necessary adjustments for your Wialon sites are recommended to be made in the administration system. If you use your own configuration file instead of the automatically generated local.conf, the Wialon Local server administrator is fully responsible for the functionality of the websites.

    If for some reason the local.conf symlink is unlinked, it should be reverted with the command:

    ln -s /home/wialon/wlocal/nginx/conf/local.conf /etc/nginx/conf.d/local.conf

In the first three configuration files, the parameter in the server_name line indicates the local IP address of your Wialon Local server. The standard configuration files will be linked to it. This IP address can be changed.

It should be understood that the webmonitor.conf and cms.conf configuration files are temporary only because they are used for temporary access to Wialon sites via IP address and port. They are also used for initial service performance checks before creating separate DNS records for websites. As soon as you create a separate DNS entry for these websites in the administration system, these files will no longer be relevant and we recommend deleting them. Up to this point, you can access these websites at the following addresses:

  • Wialon Local administration system: http:// or via the loopback address of the server itself http://localhost:8080
  • CMS Manager site: http://:8024 or via the loopback address of the server itself http://localhost:8024
  • Wialon Web site: http://:8025 or via the loopback address of the server itself http://localhost:8025

All the necessary web server logs and errors can be found in /var/log/nginx/

nginx security improvements

Depending on the security and network requirements of the server, additional nginx configuration may be required. Below, you can find the most common examples and recommendations on how to supplement a web server configuration to increase security.

  1. Extend support for TLS protocol versions at /etc/nginx/common/default.conf:

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  2. Set the maximum validity period for SSL certificates at /etc/nginx/common/default.conf:

    add_header Strict-Transport-Security "max-age=31536000;
    includeSubDomains" always;
  3. Change the active list of encryptions at /etc/nginx/common/default.conf (the entire list of encryptions can be found here):

    ssl_prefer_server_ciphers on;
  4. Manually add an SSL certificate for the administration system website at /etc/nginx/conf.d/lcm.conf:

    server {
           listen          443;
           ssl on;
           ssl_certificate /root/ssl_certificate.crt; # absolute path to the certificate
           ssl_certificate_key /root/private.key; # absolute path to its private key
           server_name     ;     

    In this case, you should set the absolute path to the certificate and its private key in the parameters above.

These settings are recommendations and are not mandatory. We do not provide technical support for setting up and configuring nginx.

Vladimir Melekestsev,Customer Service Engineer

  • 10
  • 25
  • 30
Thank you for your feedback!
Report a mistake
Text with the mistake Comment
Maximum 500 characters