-
-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix sysVinit #26
Fix sysVinit #26
Conversation
Signed-off-by: Theo Weiss <theo@m1theo.org> (github: theoweiss)
Thanks for finding the problem @theoweiss, openHAB runs on upgrade, but if openHAB's java process is killed then the karaf server gets stuck. I wasn't able to logon to the openHAB console until I:
Then killed the process with (-9 necessary):
|
I've just tested adding the following function:
Then changing kill loop to:
|
Killing two pids its not obvious to me why. Make sure to do a gradlew clean for each build or remove build/distribution/*.deb. I've noticed that the build dependencies are incomplete. Changes to control files do not trigger a new build of the deb. |
systemd works well because it registers two PIDs with the service and shuts them down appropriately, one for java owned by openHAB, and the other for Karaf server owned by openHAB.
The init.d scripts aren't aware of this second process, since it has essentially forked after it has assumed a successful start. If you force kill the java app, there's a chance that the Karaf server gets stuck. So when you kill one, you should also kill the other. I'll check again when I get home, making sure I clean the previous builds first. |
Also, I realise that both processes contain the openhab.*karaf pattern, so it should be sufficient to:
|
Hi @theoweiss, my apologies. I built a new Ubuntu 14 virtual machine, installed RC1 and then 2.0.0 and have no longer experienced the problem above on 5 attempts, the problem must have been local and I think we're good to merge, sorry for the delay! |
Very good. I'm back from travelling. I will merge this PR and then do the bintray release. |
Hopefully fixes #25
@BClark09 Could you do some testing. I've tested it on debian 7 and it looks not to bad so far. There are some ugly workarounds and we have to fix previous installations, which means we have to rely on postinst.