Looks like there is some database connection problem.
I was able to connnect using JDBC simple java connect code without any issue
Also traccar logs filled up all disk space , so i disabled the logs in traccar.xml, after that looks like the server stopped working
so i disabled logs
<entry key='web.debug'>false</entry>
<entry key='logger.enable'>false</entry>
<entry key='logger.level'>none</entry>
Is it possible to see more logs to understand better
Also found this in my traccar startup log
INFO: Starting traccar ...
INFO: lib not found: /opt/traccar/lib/extended/glazedlists/glazedlists-1.8.0_java15.jar
INFO: lib not found: /opt/traccar/lib/extended/glazedlists/commons-beanutils-1.8.2.jar
INFO: lib not found: /opt/traccar/lib/extended/glazedlists/commons-beanutils-1.8.2.jar
INFO: lib not found: /opt/traccar/lib/extended/glazedlists/glazedlists-1.8.0_java15.jar
Maybe your database got locked. You need to manually unlock it in this case.
Oh god! Thanks man, I fixed it
this helped
https://www.traccar.org/forums/topic/liquibase-waiting-for-changelog-lock/
But wondering if this could be handled in the code to such crash scenarios
HILLBILLY HACK SOLUTION as far as for MSSQL Server Restart Server Traccar server-start fails.
I found an inductive solution for MSSQL restart fails of the traccar service. However crude it may be, it has resolved 100% of my server instances with a simple sequencing technique. I found I had to DELAY starting the traccar service until AFTER ALL MSSQL services were fully started, so that when Traccar services went after the database lock, there was a database lock to 'find'. Common sense, really, can't get a lock if database is not up yet. :) In about 1 in 3 restarts, Traccar got to the 'up and ready' state, 'faster' than SQL did, even when setting traccar to delayed start. Logs indicated the database lock problem, but in closer investigation, it was just because the SQL was not fully up and running and in a ready state yet. After reinstalling SQL several times, and also getting the same error in brand new VM instances, I began to realize there was nothing inherently wrong with all those test SQLs. It was in loading sequencing and state completion. Traccar was finishing faster than SQL, randomly. That made it harder to run to ground, but once timing was identified, solving the sequencing problem, I have not had a traccar failure to start after restart failure in over 2 dozen servers since, with MSSQL servers.
Figures that MSSQL takes it own sweet time loading. :) And, sometimes, but not every time. Microsoft...whatya gonna do.
No set of settings in the services console would completely eliminate the random event of traccar trying to get a lock on a database that was not 'there' yet'. Once Traccar's 'premature lock-ulation happened' happened, many times, no combination retry console settings would bring it online without human intervention...the kiss of death with 2 dozen servers and climbing. I needed a bulletproof, never fail solution on restarting a server,
on every server, every restart, even MS-hijacking-for-unplanned windows-update-restarts(those being the worst).
SOLUTION: I scripted a VERY simple services command in Windows Task Scheduler. It checks for a running instance of the traccar service,
5 minutes after my nightly server restart. IF the traccar service is not already running, it fires it up. My SQL server instances are fully up and running by 5 minutes after server restart, then, so, if traccar's normal start has failed for any reason, this commanding task backup task gives it a do-over, and it can then acquire the needed lock. If traccar is already running, the task completes with success without refiring a news instance. if traccar is NOT running, it fires it up. Never had a single hang since that time, on dozens of instances.
Windows Task Scheduler : commanding action: [ sc.exe ] parameter: [ start traccar ] trigger: timer-based (I set mine 5 minutes after restart)
set the task to NOT fire up IF an instance is already running via the console interface
set task to repeat a number of times if unsuccessful (I set mine to 59 retries, never needs it but to be safe)
This careful set of settings and the commanding syntax has completely resolved the issue of traccar services starting a bit faster than MSSQL and hunting for a database lock that is not quite 'there' yet. A hillbilly, non-scientific hack, for sure, but it has saved me dozens of alerts in the middle of the night since perfecting this little technique.
You will want to open a command window as an administrator, run sc.exe queryex to verify that your traccar service name is traccar etc, but this has done the trick for me, without question, on dozens of servers without fail.
hope it is helpful to other mssql users.
Traccar fails to start, it was working fine for more than a 3 weeks but suddenly after server restart its not connecting to mysql server and throws below error
I was able to connect to the same database, same credentials, JDBC connector using a simple java code
Traccar version 3.14 running on AWS EC2 AMI, mysql 5.7.11
Please help
Below is the attached traccar wrapper log