"No systemd support" error after updating to Traccar 4.10 using Docker
You should disable health check in the config:
<entry key='web.healthCheck'>false</entry>You can also just safely ignore the warning.
Ok. Thanks!
Hi Anton, what file can that key be found in? I checked both files in the /opt/traccar/conf directory and it is not there. Also, will disabling health check mean the server will stop restarting itself when it becomes for some reason unresponsive?
also, I am running a fresh install of Version: 4.11
If you don't have systemd, the health check won't work anyway.
I am seeing in the log that every 10 minutes the server is trying to start. Is this behavior not caused by the keep-alive function built into the newer versions of the Server?
By the way, this is causing a bunch of error messages in the log, as an instance of the server is already running. Now I have an ever growing number of java instances running as a consequence. This was not happening with a version of the Server I just replaced (4.6-SNAPSHOT).
This is what I am seeing after I kill all java processes and start the traccar server:
2020-12-15 10:01:53 INFO: HikariPool-1 - Starting...
2020-12-15 10:01:53 WARN: Registered driver with driverClassName=com.mysql.jdbc.Driver was not found, trying direct instantiation.
2020-12-15 10:01:53 INFO: HikariPool-1 - Start completed.
2020-12-15 10:01:55 INFO: Clearing database change log checksums
2020-12-15 10:01:55 INFO: Successfully acquired change log lock
2020-12-15 10:01:55 INFO: Successfully released change log lock
2020-12-15 10:01:55 INFO: Successfully acquired change log lock
2020-12-15 10:01:55 INFO: Can not use class liquibase.parser.core.yaml.YamlChangeLogParser as a Liquibase service because org.yaml.snakeyaml.constructor.BaseConstructor is not in the classpath
2020-12-15 10:01:55 INFO: Can not use class liquibase.parser.core.json.JsonChangeLogParser as a Liquibase service because org.yaml.snakeyaml.constructor.BaseConstructor is not in the classpath
2020-12-15 10:01:57 INFO: Reading from traccardb.DATABASECHANGELOG
2020-12-15 10:01:58 INFO: Reading from traccardb.DATABASECHANGELOG
2020-12-15 10:01:58 INFO: Successfully released change log lock
2020-12-15 10:01:58 INFO: Logging initialized @7085ms to org.eclipse.jetty.util.log.Slf4jLog
2020-12-15 10:01:59 INFO: Your platform does not provide complete low-level API for accessing direct buffers reliably. Unless explicitly requested, heap buffer will always be preferred to avoid potential system instability.
2020-12-15 10:02:00 INFO: Operating system name: Linux version: 3.16.6-042stab141.42 architecture: amd64
2020-12-15 10:02:00 INFO: Java runtime name: OpenJDK 64-Bit Server VM vendor: ojdkbuild version: 11.0.8+10-LTS
2020-12-15 10:02:00 INFO: Memory limit heap: 1024mb non-heap: 0mb
2020-12-15 10:02:00 INFO: Character encoding: UTF-8 charset: UTF-8
2020-12-15 10:02:00 INFO: Version: 4.11
2020-12-15 10:02:00 INFO: Starting server...
2020-12-15 10:02:00 WARN: Failed to find a usable hardware address from the network interfaces; using random bytes: 92:55:43:ef:52:51:c9:65
2020-12-15 10:02:01 INFO: jetty-9.4.33.v20201020; built: 2020-10-20T23:39:24.803Z; git: 1be68755656cef678b79a2ef1c2ebbca99e25420; jvm 11.0.8+10-LTS
2020-12-15 10:02:01 INFO: Started o.t.w.@71a2df1{/,null,AVAILABLE}
2020-12-15 10:02:01 INFO: DefaultSessionIdManager workerName=node0
2020-12-15 10:02:01 INFO: No SessionScavenger set, using defaults
2020-12-15 10:02:01 INFO: node0 Scavenging every 600000ms
2020-12-15 10:02:04 INFO: Started o.e.j.s.ServletContextHandler@2ea4e762{/,null,AVAILABLE}
2020-12-15 10:02:04 INFO: Started ServerConnector@40113163{HTTP/1.1, (http/1.1)}{0.0.0.0:8082}
2020-12-15 10:02:04 INFO: Started @12884ms
2020-12-15 10:02:04 WARN: No systemd support - Unable to load library 'systemd':
libsystemd.so: cannot open shared object file: No such file or directory
libsystemd.so: cannot open shared object file: No such file or directory
Native library (linux-x86-64/libsystemd.so) not found in resource path (tracker-server.jar) - UnsatisfiedLinkError (... < HealthCheckService:40 < Main:115 < *:149 < *:110)I don't really understand why it would cause multiple instances of Traccar, but if you want, you can always disable it in the config.
Thank you for a hint, but could you please tell me what should I disable? As discussed above, the web.healthCheck param. is not available to me and I do not see other suitable candidates neither in the list of other config parameters nor the ones I see in the default.xml and traccar.xml files.
Why is web.healthCheck not available to you?
I might have not understood what you meant when you wrote "If you don't have systemd, the health check won't work anyway." but I thought you meant that the param was not going to be effective on my system.
Anyways, I added the <entry key='web.healthCheck'>false</entry> key into the traccar.xml, killed the java processes, restarted the Server and indeed see no change. At least the log suggests that new instances of traccar are being launched and I still see new java processes spawning but this might be normal(?). I have no sensors sending data at this time, so this behavior is puzzling. Below is a couple of lines from the log.
2020-12-15 19:35:57 WARN: Port 5180 is disabled due to conflict
2020-12-15 19:35:57 WARN: Port 5171 is disabled due to conflict
2020-12-15 19:35:57 WARN: Port 5004 is disabled due to conflict
2020-12-15 19:35:57 WARN: Port 5004 is disabled due to conflict
2020-12-15 19:35:57 WARN: Port 5188 is disabled due to conflict
2020-12-15 19:35:57 WARN: Port 5037 is disabled due to conflict
2020-12-15 19:35:57 WARN: Port 5022 is disabled due to conflict
2020-12-15 19:35:57 WARN: Port 5001 is disabled due to conflict
2020-12-15 19:35:57 WARN: Port 5001 is disabled due to conflict
2020-12-15 19:35:57 WARN: Port 5007 is disabled due to conflict
2020-12-15 19:35:57 WARN: Port 5158 is disabled due to conflict
2020-12-15 19:35:57 WARN: Port 5024 is disabled due to conflict
2020-12-15 19:35:57 WARN: Port 5135 is disabled due to conflict
2020-12-15 19:35:57 WARN: Port 5039 is disabled due to conflict
2020-12-15 19:35:57 WARN: Port 5039 is disabled due to conflict
2020-12-15 19:35:57 WARN: Port 5124 is disabled due to conflict
2020-12-15 19:35:57 WARN: Port 5196 is disabled due to conflict
2020-12-15 19:35:57 WARN: Port 5059 is disabled due to conflict
2020-12-15 19:35:57 WARN: Port 5102 is disabled due to conflict
2020-12-15 19:35:57 WARN: Port 5021 is disabled due to conflict
2020-12-15 19:35:57 WARN: Port 5083 is disabled due to conflict
2020-12-15 19:35:57 WARN: Port 5133 is disabled due to conflict
2020-12-15 19:35:57 INFO: jetty-9.4.30.v20200611; built: 2020-06-11T12:34:51.929Z; git: 271836e4c1f4612f12b7bb13ef5a92a927634b0d; jvm 11.0.5+10-LTS
2020-12-15 19:35:57 INFO: Started o.t.w.@65af05b2{/,null,AVAILABLE}
2020-12-15 19:35:57 INFO: DefaultSessionIdManager workerName=node0
2020-12-15 19:35:57 INFO: No SessionScavenger set, using defaults
2020-12-15 19:35:57 INFO: node0 Scavenging every 600000ms
2020-12-15 19:35:59 INFO: Started o.e.j.s.ServletContextHandler@2d23a5be{/,null,AVAILABLE}
2020-12-15 19:35:59 WARN: Web server start failed - Address already in use - BindException (... < WebServer:172 < Main:145 < *:110)It looks like you already have another instance of Traccar running. You should kill it first before starting.
This is what I do.
- I issue systemctl stop traccar.service,
- kill all java processes,
- systemctl start traccar.service.
It starts normally, but then after 10 minutes "something" is trying to start new instances of the server - judging by what I see in the log. The number of java processes goes up as well. The server seems to function normally regardless - I can log into the web app.
Wait. You do have systemd?
Hi,
I'm using Traccar on Docker with the tag
4.10-alpineand since I updated to this latest version, the following warning message is showing on the log during startup:Alpine Linux doesn't really support systemd out of the box and I assume this is the cause for this warning however I just want to know for what this is used and if this is something I should be concerned. So far, Traccar is working as expected, no strange behaviour due to this.
Thanks,
Rafael