Need a guide...

[Fuzzy]

Originally Posted by EnterNoEscape

That's probably true. You're running it in console mode. The only thing that will break it out of that mode and shutdown correctly is Ctrl-C (SIGINT). JSW doesn't appear to handle SIGTERM.

Edit: I know that you need to tie the docker container up with something to keep it from shutting down immediately, but I think the solution should be to start OpenDCT like the service is actually is. When the the container gets SIGTERM on PID 1, it should trigger the service to stop gracefully. I believe this is what the SageTV container does and to tie the initial process up, it just sleeps for infinity.

Hmmm that's a shame, as console mode it's what allows viewing of the log from in unRAID's UI. That said, docker kill --signal=SIGINT doesn't seem to close it down either, or at least the shutdown messages don't make it to the log.

[EnterNoEscape]

Originally Posted by Fuzzy

Hmmm that's a shame, as console mode it's what allows viewing of the log from in unRAID's UI. That said, docker kill --signal=SIGINT doesn't seem to close it down either, or at least the shutdown messages don't make it to the log.

I'm not sure SIGINT is actually hitting the script. Though I do agree that I like having the real log there like that. That was the other thing missing. The logs are under /var/log/opendct, this would be a folder worth mapping so users can easily get logs via SMB.

[Fuzzy]

There is a more in the jsw docs regarding shutdowns that there is no difference between service or console on Unix environments, so I'm not sure there's much off a difference here. In either case, I will try a test build as a service and see if it closes smoothly. I think we'll still be able to get the log to the ui if the script tail's the log file.

I'll also see if the log can be redirected to the share.

[EnterNoEscape]

Originally Posted by Fuzzy

There is a more in the jsw docs regarding shutdowns that there is no difference between service or console on Unix environments, so I'm not sure there's much off a difference here. In either case, I will try a test build as a service and see if it closes smoothly. I think we'll still be able to get the log to the ui if the script tail's the log file.

I'll also see if the log can be redirected to the share.

The shutdown from the JVM's perspective is exactly the same, but how it is initiated is different between console mode and service mode. You can see this in the script used to initiate either mode.

[Wrx4me]

I am am trying to test the Sagetv docker in unRAID but I am having a similar issue as Ugadata with the docker Opendct not detecting my HDHR Prime tuners. I do not have an alternate Opendct properties file to replace with as he did. Is there a work around for those of us without another version running on the network? My main Server is running Sagedct.

[Fuzzy]

Originally Posted by EnterNoEscape

The shutdown from the JVM's perspective is exactly the same, but how it is initiated is different between console mode and service mode. You can see this in the script used to initiate either mode.

I think I may have this partially figured out. Docker will only send SIGTERM to PID 1 (expecting that it is the 'main process' that the container is working). In the case of opendct, PID 1 is the shell that is processing the console-only or service scripts. sending SIGTERM to the shell that has launched child processes does not relay the SIGTERM to the child processes, which is why it was never getting to java.

I think the 'cleanest' fix would be to call the java executable directly from the docker, not using the wrapper and/or scripts - but I don't know how to do that, or if it's even feasible with the way opendct is built.

Alternatively, I'm testing using supervisord as PID 1 and having it launch opendct. supervisord will relay signals to child processes, so hopefully this will work - but doing so definitely will kill the ability to monitor the log from opendct's UI (which is why I'd rather launch opendct.Main directly from a java command, if possible).

I'm not really familiar enough with java bundling and such to know if/how to launch it that way though - appreciate some pointers if possible.

[EnterNoEscape]

The command line used to launch OpenDCT is actually in wrapper.log:

INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[0] : /usr/bin/java
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[1] : -Dopendct_log_root=/var/log/opendct
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[2] : -Dconfig_dir=/etc/opendct/conf
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[3] : -Ddaemon_mode=true
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[4] : -XX:ErrorFile=/var/log/opendct/hs_err_pid%p.log
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[5] : -verbose:gc
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[6] : -XX:+UseG1GC
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[7] : -Xms128m
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[8] : -Xmx768m
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[9] : -Djava.library.path=/opt/opendct/jsw/lib:/opt/opendct/lib
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[10] : -classpath
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[11] : /opt/opendct/jsw/lib/wrapper.jar:/opt/opendct/lib/opendct-0.5.11.jar:/opt/opendct/lib/cling-core-2.1.0.jar:/opt/opendct/lib/log4j-api-2.5.jar:/opt/opendct/lib/log4j-core-2.5.jar:/opt/opendct/lib/jna-4.2.1.jar:/opt/opendct/lib/jna-platform-4.2.1.jar:/opt/opendct/lib/nanohttpd-2.3.0.jar:/opt/opendct/lib/nanohttpd-nanolets-2.3.0.jar:/opt/opendct/lib/gson-2.6.2.jar:/opt/opendct/lib/javacpp-1.2.jar:/opt/opendct/lib/ffmpeg-3.1.2-1.2.jar:/opt/opendct/lib/ffmpeg-3.1.2-1.2-linux-x86_64.jar:/opt/opendct/lib/seamless-util-1.1.1.jar:/opt/opendct/lib/seamless-http-1.1.1.jar:/opt/opendct/lib/seamless-xml-1.1.1.jar
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[12] : -Dwrapper.key=QqYNQ_89M9BlxBYL
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[13] : -Dwrapper.port=32000
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[14] : -Dwrapper.jvm.port.min=31000
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[15] : -Dwrapper.jvm.port.max=31999
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[16] : -Dwrapper.pid=82
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[17] : -Dwrapper.version=3.2.3
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[18] : -Dwrapper.native_library=wrapper
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[19] : -Dwrapper.service=TRUE
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[20] : -Dwrapper.cpu.timeout=10
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[21] : -Dwrapper.jvmid=1
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[22] : org.tanukisoftware.wrapper.WrapperSimpleApp
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[23] : opendct.Main

This is all relative to the jsw directory; I recommend launching from that folder. If you remove 12-22, and turn all of that into one line with each command separated by a space, it should actually run. The only problem is you will not get any library version changes doing it this way and there will be no recovery logic (provided by JSW) if the program actually fails.

[Fuzzy]

Originally Posted by EnterNoEscape

The command line used to launch OpenDCT is actually in wrapper.log:

INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[0] : /usr/bin/java
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[1] : -Dopendct_log_root=/var/log/opendct
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[2] : -Dconfig_dir=/etc/opendct/conf
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[3] : -Ddaemon_mode=true
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[4] : -XX:ErrorFile=/var/log/opendct/hs_err_pid%p.log
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[5] : -verbose:gc
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[6] : -XX:+UseG1GC
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[7] : -Xms128m
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[8] : -Xmx768m
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[9] : -Djava.library.path=/opt/opendct/jsw/lib:/opt/opendct/lib
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[10] : -classpath
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[11] : /opt/opendct/jsw/lib/wrapper.jar:/opt/opendct/lib/opendct-0.5.11.jar:/opt/opendct/lib/cling-core-2.1.0.jar:/opt/opendct/lib/log4j-api-2.5.jar:/opt/opendct/lib/log4j-core-2.5.jar:/opt/opendct/lib/jna-4.2.1.jar:/opt/opendct/lib/jna-platform-4.2.1.jar:/opt/opendct/lib/nanohttpd-2.3.0.jar:/opt/opendct/lib/nanohttpd-nanolets-2.3.0.jar:/opt/opendct/lib/gson-2.6.2.jar:/opt/opendct/lib/javacpp-1.2.jar:/opt/opendct/lib/ffmpeg-3.1.2-1.2.jar:/opt/opendct/lib/ffmpeg-3.1.2-1.2-linux-x86_64.jar:/opt/opendct/lib/seamless-util-1.1.1.jar:/opt/opendct/lib/seamless-http-1.1.1.jar:/opt/opendct/lib/seamless-xml-1.1.1.jar
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[12] : -Dwrapper.key=QqYNQ_89M9BlxBYL
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[13] : -Dwrapper.port=32000
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[14] : -Dwrapper.jvm.port.min=31000
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[15] : -Dwrapper.jvm.port.max=31999
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[16] : -Dwrapper.pid=82
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[17] : -Dwrapper.version=3.2.3
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[18] : -Dwrapper.native_library=wrapper
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[19] : -Dwrapper.service=TRUE
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[20] : -Dwrapper.cpu.timeout=10
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[21] : -Dwrapper.jvmid=1
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[22] : org.tanukisoftware.wrapper.WrapperSimpleApp
INFO   | wrapper  | 2016/10/24 16:11:40.071 | Command[23] : opendct.Main

This is all relative to the jsw directory; I recommend launching from that folder. If you remove 12-22, and turn all of that into one line with each command separated by a space, it should actually run. The only problem is you will not get any library version changes doing it this way and there will be no recovery logic (provided by JSW) if the program actually fails.

I'll give that a shot later hopefully. Thank you. Regarding the libraries, i 'think' you can pass a wildcard to the -cp argument (/opt/opendct/lib/*) and it'll pick up all the .jars in that folder - so that should deal with updates without having to update the command every time. hopefully.

[stuckless]

Something else to consider... Bash supports "trap" for trapping sigterm, so you could catch the sigterm in the script and forward it.

http://unix.stackexchange.com/questi...-child-in-bash

[Fuzzy]

Originally Posted by stuckless

Something else to consider... Bash supports "trap" for trapping sigterm, so you could catch the sigterm in the script and forward it.

http://unix.stackexchange.com/questi...-child-in-bash

I had looked at that - but was a bit concerned about it being able to handle nested bash scripts. In the case of the current setup of openDCT, I've got my installation/launch script in the docker image, which is launching a script to start the service, which is launching a jsw script that is handling the generation of the java command line and finally launching it.

[stuckless]

Originally Posted by Fuzzy

Actually, at some point, the container definition changed to pointing to /mnt/user/appdata/sagetv instead of /mnt/user/apps/sagetv. In either case, /mnt/user/appdata/sagetv should be shared at \\<unRAID>\appdata\sagetv.

Originally Posted by Fuzzy

I had looked at that - but was a bit concerned about it being able to handle nested bash scripts. In the case of the current setup of openDCT, I've got my installation/launch script in the docker image, which is launching a script to start the service, which is launching a jsw script that is handling the generation of the java command line and finally launching it.

Something else to look at (because there is never enough to look at ) is that if you use the phusion as the base image (I moved sagetv to phusion) it has a couple nice features. One of those is that is support "daemons" and it manages keeping them alive and shutting them down.

https://github.com/phusion/baseimage...tional_daemons

I don't use this for sagetv since sagetv has it's startup script and that script manages keeping it alive (among other things). But this discussion has me thinking... how does sagetv handle the SIGTERM (ie, does it gracefully shut down)

[Fuzzy]

Originally Posted by stuckless

Something else to look at (because there is never enough to look at ) is that if you use the phusion as the base image (I moved sagetv to phusion) it has a couple nice features. One of those is that is support "daemons" and it manages keeping them alive and shutting them down.

https://github.com/phusion/baseimage...tional_daemons

I don't use this for sagetv since sagetv has it's startup script and that script manages keeping it alive (among other things). But this discussion has me thinking... how does sagetv handle the SIGTERM (ie, does it gracefully shut down)

Currently, I'm questioning whether the sage docker is gracefully shutting down as well. I glanced at a few logs, and it don't recall seeing the typical shutdown actions, so I'm guessing it's not getting the SIGTERM to the sage process either.

[UgaData]

Originally Posted by Wrx4me

I am am trying to test the Sagetv docker in unRAID but I am having a similar issue as Ugadata with the docker Opendct not detecting my HDHR Prime tuners. I do not have an alternate Opendct properties file to replace with as he did. Is there a work around for those of us without another version running on the network? My main Server is running Sagedct.

It should be noted that I was able to detect my cablecard device (Ceton Infinity Eth6). Not only could I detect the docker instance of OpenDCT, I could also detect the other OpenDCT instances on my network.
The issue I had was after configuring the tuner, I would get No Signal when I tried to tune a channel.

One of your options is to wait, watch this thread, and once the OpenDCT Docker install issues are worked out, try installing it again.

Another option would be to change from SageDCT to OpenDCT. Once OpenDCT is working with your existing Sage setup, you have can point the Sage Docker to use the existing (non-docker) OpenDCT instance for testing (Keep in mind both systems can't use the same tuner concurrently). This would then give you an OpenDCT properties file to copy (keep in mind your mileage may vary). I am not recommending you do this, just that is is a possible path for testing.

[EnterNoEscape]

There are a few key issues that need to be worked out. The one that's most likely affecting people is that upload ID isn't enabled by default and the script that's supposed to set it isn't actually doing that. If you don't want to fiddle with that, I recommend waiting for the container to be updated.

[stuckless]

Originally Posted by Fuzzy

Currently, I'm questioning whether the sage docker is gracefully shutting down as well. I glanced at a few logs, and it don't recall seeing the typical shutdown actions, so I'm guessing it's not getting the SIGTERM to the sage process either.

The phusion container appears to send SIGTERM to all process during shutdown, and waits... (from what I can tell in the code). Whether or not makes it to the java process... not sure. I do know that when I run docker locally there is a significant pause when I stop the container, which leads me to think that it's waiting for stuff to shut down.

[Wrx4me]

Originally Posted by UgaData

It should be noted that I was able to detect my cablecard device (Ceton Infinity Eth6). Not only could I detect the docker instance of OpenDCT, I could also detect the other OpenDCT instances on my network.
The issue I had was after configuring the tuner, I would get No Signal when I tried to tune a channel.

One of your options is to wait, watch this thread, and once the OpenDCT Docker install issues are worked out, try installing it again.

Another option would be to change from SageDCT to OpenDCT. Once OpenDCT is working with your existing Sage setup, you have can point the Sage Docker to use the existing (non-docker) OpenDCT instance for testing (Keep in mind both systems can't use the same tuner concurrently). This would then give you an OpenDCT properties file to copy (keep in mind your mileage may vary). I am not recommending you do this, just that is is a possible path for testing.

Great! Thanks for the feedback, I'll hang tight and wait for the issues to get worked out. No sense incurring the wrath of the family by mucking around with my Server that has been rock solid for over 6 years

[EnterNoEscape]

Originally Posted by stuckless

The phusion container appears to send SIGTERM to all process during shutdown, and waits... (from what I can tell in the code). Whether or not makes it to the java process... not sure. I do know that when I run docker locally there is a significant pause when I stop the container, which leads me to think that it's waiting for stuff to shut down.

It's worth noting though that at least in unRAID after 10 seconds, the container will close regardless of a clean shutdown.

[stuckless]

Originally Posted by EnterNoEscape

It's worth noting though that at least in unRAID after 10 seconds, the container will close regardless of a clean shutdown.

That's not cool Hopefully SageTV has finished writing to the Wiz.bin before then

[Fuzzy]

Originally Posted by stuckless

That's not cool Hopefully SageTV has finished writing to the Wiz.bin before then

I was hoping there was a setting to extend that time. The docker stop command DOES have a -time option to set how long it will wait after SIGTERM before it sends SIGKILL, but I don't see an option in unraid to set the default for that.

[EnterNoEscape]

Originally Posted by stuckless

That's not cool Hopefully SageTV has finished writing to the Wiz.bin before then

I've seen times when SageTV got in it's own way at completing that task even with a "clean" shutdown, but I agree. If it's possible to ensure that all pending writes are written, it is strongly preferred. I can say because I worked around some of that, there is up to a 128k window of unwritten data that might be dangling at any given moment. The exception would be when the database is being rebuilt/compacted, but there are safeguards for that situation. The write mode used for the database causes writes to be immediately committed to disk, so you're likely safe in regards to everything SageTV intended to write.