No, the "kill" message did not disappear - no matter if I use the original init script or your version (see Edit1 of my previous post).

The packages "sysvinit-core" and "sysvinit-utils" are still there and can be installed - as I removed systemd completely and the machine still booted I think it's save to assume that they postponed the removal of sysv init.

Regards
Peter

-----


Edit1:

For reference - when running the jar directly from the shell (without all the options):

----start stdout -------
root@eap-controller:~# java -Deap.home="/opt/tplink/EAPController/" -cp /opt/tplink/EAPController/lib/com.tp-link.eap.start-0.0.1-SNAPSHOT.jar:/opt/tplink/EAPController/lib/*:/opt/tplink/EAPController/external-lib/* com.tp_link.eap.start.EapMain start
log4j:WARN No appenders could be found for logger (com.tp_link.eap.util.system.SystemUtil).
log4j:WARN Please initialize the log4j system properly.
========EAP_LINUX_MONGOD_KEY======
mongodPath = "/opt/tplink/EAPController/bin/mongod" --port 27017 --dbpath "/opt/tplink/EAPController/data/db" -pidfilepath "/opt/tplink/EAPController/data/mongo.pid" --logappend --logpath "/opt/tplink/EAPController/logs/mongod.log" --nohttpinterface --bind_ip 127.0.0.1
repairCommand = "/opt/tplink/EAPController/bin/mongod" --repair --dbpath "/opt/tplink/EAPController/data/db" --logappend --logpath "/opt/tplink/EAPController/logs/mongod.log"
"/opt/tplink/EAPController/bin/mongod" --port 27017 --dbpath "/opt/tplink/EAPController/data/db" -pidfilepath "/opt/tplink/EAPController/data/mongo.pid" --logappend --logpath "/opt/tplink/EAPController/logs/mongod.log" --nohttpinterface --bind_ip 127.0.0.1
Killed
---- end stdout------


Edit2:

... and again with all the options:

--- start stdout ---
root@eap-controller:~# java -Deap.home="/opt/tplink/EAPController/" -Xms128m -Xmx1024m -XX:MaxHeapFreeRatio=60 -XX:MinHeapFreeRatio=30 -XX:+UseSerialGC -XX:+HeapDumpOnOutOfMemoryError -cp /opt/tplink/EAPController/lib/com.tp-link.eap.start-0.0.1-SNAPSHOT.jar:/opt/tplink/EAPController/lib/*:/opt/tplink/EAPController/external-lib/* com.tp_link.eap.start.EapMain start
log4j:WARN No appenders could be found for logger (com.tp_link.eap.util.system.SystemUtil).
log4j:WARN Please initialize the log4j system properly.
========EAP_LINUX_MONGOD_KEY======
mongodPath = "/opt/tplink/EAPController/bin/mongod" --port 27017 --dbpath "/opt/tplink/EAPController/data/db" -pidfilepath "/opt/tplink/EAPController/data/mongo.pid" --logappend --logpath "/opt/tplink/EAPController/logs/mongod.log" --nohttpinterface --bind_ip 127.0.0.1
repairCommand = "/opt/tplink/EAPController/bin/mongod" --repair --dbpath "/opt/tplink/EAPController/data/db" --logappend --logpath "/opt/tplink/EAPController/logs/mongod.log"
"/opt/tplink/EAPController/bin/mongod" --port 27017 --dbpath "/opt/tplink/EAPController/data/db" -pidfilepath "/opt/tplink/EAPController/data/mongo.pid" --logappend --logpath "/opt/tplink/EAPController/logs/mongod.log" --nohttpinterface --bind_ip 127.0.0.1
Killed
--- end stdout ---


Edit3:

When "watch"ing netstat, while starting the jar, I can see mongod listening on 127.0.0.1:27017 and two ports occupied by the same java process (TCP/1099 and a more or less random TCP port above 30000).
Then mongod stops or gets killed and java exits with the "Killed" message.

R1D2 wrote

mongodb listens on port 27017. Port 1099 is rmiregistry. The EAPController listens on ports 8043 and 8088.

Just to make sure: you are aware that on Linux there is no popup appearing as in the Windows version of EAPC? You need to start a browser and go to either localhost:8088 or localhost:8043/login.

I'm absolutely aware that there is no pop-up and there is no X server running on my machine where the pop-up could be displayed if there was one.
There is nothing listening on ports TCP/8088 or TCP/8043 - the java process exits before it gets that far.

Otherwise, I have no idea why it doesn't run on your Linux.

As this is a fresh install of Debian Stretch on a vSphere VM and the problem also exists on Ubuntu 16.04 LTS (which is in the list of supported OSes) on the same VM the conclusion is that the downloadable package got some issues.

Thanks again for your efforts
I will be opening a ticket with support as soon as possible

Regards
Peter


---

Edit1:

Although the issue is most likely with the package, I still HAD to try something else.
On a VPS of mine which has been dist-upgraded since Debian 7 the package seems to be working.

I'm wondering what the difference to a fresh Debian 9 may be?

I'll be doing another test with another VM on another vSphere host and report back here, to have everything in one place.

Had same problem and issue turned out to be OpenJRE. Switching to OracleJRE did not work properly so I cut the losses and started afresh with LUbuntu 17.04 and OracleJDK

Hi R1D2, PeterL, MikeB,

i have exactly the same problem on Debian Jessie Physical Hardware, Debian Jessie VM (Proxmox), Ubuntu 16.4 LTS VM (Proxmox)
vm is not the problem , same problem on, physical
but, just to be sure, i try to install Ubuntu on physical

R1D2 wrote

In the first place, the Java environment would have to be supported by Synology for their platform, which AFAIK is based on their own custom Linux system.
But you probably would not have much fun running Java on an embedded system, even if it is x86-based.

actually, the synology itself supports java.
and sombody already build a package for unifi controllers.
http://synology.acmenet.ru/





I'm not from TP-Link, but I guess there is no port to 32-bit Linux b/c most business class servers use 64-bit processors those days (remember, the EAPs are targeting business users). Even 32-bit embedded x86-based platforms are becoming more and more obsolete in last years. As for XP/Vista: see, UNIX, the predecessor of Linux, was ported 40 years ago even on 128-bit platforms and did widely support 64-bit for mass market platforms (!) already in the early 1990's, when Microsoft just was introducing the "world's first 32-bit Operating System" (on their supported platforms; they always forgot to mention this in the ads and in the TV spots). So, a comparison of those different ecospheres are by no means a reliable indicator for the technical base of a software application.

cant argue about that.

I did some more testing in regards to the java app exiting in middle of the startup process.

I switched to another vSphere host (vSphere 6.5 on HP ProLiant hardware), with exactly the same results.
As I had another system around for testing I also tried running it in a Hyper-V 2012R2 VM on desktop hardware (HP EliteDesk 800 G1), which also showed exactly the same results.


Soooooo ... Debian Stretch in a VM on IBM/Lenovo xServer running vSphere 6.5 -> no go
Debian Stretch in a VM on HP ProLiant running vSphere 6.5 -> no go
Debian Stretch in a VM on HP desktop running Hyper-V 2012R2 (licensed, not free) -> no go

Debian Stretch in a VM on unknown server hardware running Linux and KVM -> works
Debian Stretch on unknown desktop hardware in a DC run by OVH -> works


jeanphi reported negative results of VMs running on Proxmox - was this OpenVZ containers or KVM VMs?

I'm tempted to post a joke about java portability ...

Regards
Peter


Edit1:
I've also tried Debian 7.11, Debian 8.3 and Ubuntu 16.04 LTS in vSphere VMs and all show the same - non working - result.


Edit2:
I've forgotten to mention, that available memory is NOT the problem.
The app does not start on a 4GB memory system but launches without an issue on a 1GB memory system.

MikeB wrote

Had same problem and issue turned out to be OpenJRE. Switching to OracleJRE did not work properly so I cut the losses and started afresh with LUbuntu 17.04 and OracleJDK

Hi,
in this case there is no other JRE involved than the one included with the EAP controller (Oracle 1.7).
I also tried current version of the Orcale JRE and different versions of OpenJDK before.

Regards
Peter