-
Notifications
You must be signed in to change notification settings - Fork 444
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
Volumes are not correct #12
Comments
I believe the /var/run is or was a requirement for running unifi under On Wed, Nov 9, 2016, 10:35 PM Josh Behrends notifications@github.com
|
Writing to "/usr/..." is not good form because it conflicts with the Filesystem Hierarchy Standard which intends it for read-only user data.
Again, After downloading the latest .deb package (also observing what the package scripts do), I noticed that Ubiquiti target Reading the init script provides good details about how and from where the software normally runs... At a guess, odd behaviour is seen because unifi controller is not being run via the init script (or systemd). It simply runs When trying to shoehorn in applications not intentionally coded to be run as a micro-service, one might miss a whole bunch of things the init script or service type files do... For example, the init script does symbolic linking (via a
Another key observation is that the process is run with cd ${BASEDIR} So the application probably expects Arguably, perhaps they should've rather gone with Also, JSVC was used to wrap the java process. Note all the Java JSVC options for running the java app as a service in unix. It uses the pidfile and output to SYSLOG. So ordinarily, it'd have logged to syslog, not files. JSVC_OPTS="${JSVC_OPTS}\
-home ${JAVA_HOME} \
-cp /usr/share/java/commons-daemon.jar:${BASEDIR}/lib/ace.jar \
-pidfile ${PIDFILE} \
-procname ${NAME} \
-outfile SYSLOG \
-errfile SYSLOG \
${JSVC_EXTRA_OPTS} \
${JVM_OPTS}" Also, a main class was specified Hope the above info helps provide pointers to try refactor the docker image. I might try submit a PR the replicates the symlinking and a perhaps uses a minimal init parent (in case of orphaned / defunct processes / zombie reaping problem). But this is a good example of how trying to retrofit a full blown Unix style app into docker is a pain. |
fixed issue #12 and refactored how unifi processes are run
Thank you @JPvRiel for the pull request I went ahead and merged it, this issue should be closed now. |
@jacobalberty well, I created a new issue where the java jsvc stop command had a typo. Fixed that with a 2nd PR. Apologies, should've have double checked ending the process worked cleanly. I've checked the logs, things seem to proceed normally. E.g. I see I did see just one
|
Tested vanilla package in a VM. Indeed, that warning message seems normal. |
Revert "fixed issue #12 and refactored how unifi processes are run"
Had to back out the previous pull request. unifi.sh was missing, need to do |
Sorry, whoops, fixed - that's why one shouldn't commit at ~3AM (it GMT +2 my side)! |
I'm going to go through in a minute and straighten out the commits to get
everything resolved and back up to speed. I think it would be better to
install dumb-init from the upstream package (possibly pinned to a specific
version) though rather than including it in the repository for unifi-docker
directly to provide more information on the source for the paranoid. I've
forgotten the specifics of version pinning in Debian ATM but I can look at
it later this evening (I'm GMT -6)
…On Jan 9, 2017 2:56 PM, "JPvRiel" ***@***.***> wrote:
Sorry, whoops, fixed - that's why one shouldn't commit at ~3AM (it GMT +2
my side)!
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#12 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB42ghdicC-474zUqnBJJbDdqNf0ydpHks5rQp7zgaJpZM4KuRaU>
.
|
Sure, makes sense! The PR went from something simple (fix volume mounts) to trying to address more (safeguard against Unix orphaned process handling, graceful shutdown, etc). So some caution is warranted. I had a look, but unfortunately debian only has If you'd like to decouple this, to simply fix the original issue #12, the key changes needed in the Dockerfile are: ENV BASEDIR=/usr/lib/unifi \
DATADIR=/var/lib/unifi \
RUNDIR=/var/run/unifi \
LOGDIR=/var/log/unifi
RUN ln -s ${BASEDIR}/data ${DATADIR} && \
ln -s ${BASEDIR}/run ${RUNDIR} && \
ln -s ${BASEDIR}/logs ${LOGDIR} In retrospect, I should have rather split this as two PRs, one fixing #12, the other being quite a major refactor. |
Approaches that can be taken:
Maybe we can get away without needing an init process and just rely on # trap SIGTERM (or SIGINT or SIGHUP) and send `-stop`
trap "echo 'Stopping unifi controller service (TERM signal caught).'; ${JSVC} -nodetach -pidfile ${PIDFILE} -stop ${MAINCLASS} stop; exit 0" 1 2 15
# keep attached to shell so we can wait on it
echo 'Starting unifi controller service.'
${JSVC} -nodetach ${JSVC_OPTS} ${MAINCLASS} start &
wait
echo "WARN: unifi service process ended without being singaled? Check for errors in ${LOGDIR}." >&2
exit 1 AFAIK, the above will:
My rough understanding is that it might work okay, provided exec style Trapping signals in Docker containers
Simplest approach could be to trust Clean shutdown? Can sessions survive a jsvc stop/start ?
|
Hi, since Revert "fixed issue #12 and refactored how unifi processes are run" the Stripe payment api does no longer work correctly. To be able to use the Stripe payment Api, Java need to support TLS 1.2. Java7 does not support it, but Java8 (debian jessie backports) does. Is it possible to re-add openjdk-8-jre-headless from debian jessie backports to fix this issue? |
Was stripe payment api working before that revert? |
I did not try it out yet, but manually installing openjdk-8-jre-headless and purging the old java 7 version within the running container does fix the issue. |
was there any technical reason for downgrading from openjdk-8-jre back to ...7-jre? Did it break something else? |
We never used openjdk 8 in a working build. That pull request was missing a
file which resulted in a broken build and I haven't had a chance to sort it
out and check the changes back in properly fixed
…On Jan 18, 2017 4:00 PM, "fflo" ***@***.***> wrote:
was there any technical reason for downgrading from openjdk-8-jre back to
...7-jre? Did it break something else?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#12 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB42gqn5i8HyucqxSbpYvmmiTOJ3oFn0ks5rTouSgaJpZM4KuRaU>
.
|
It really took me some time to debug why the Stripe payment api was not working with your image; the error message trying to finish the payment is misleading. |
By default, the debian package from Ubiquity pulls in Java 7 on Jessie, unless one explicitly pulls in Java 8. When I attempted re-factoring it, I decided to pull in Java 8 as part of improving the the image, given Java 7 is getting fairly old and has some limitations. |
Revert "Revert "fixed issue #12 and refactored how unifi processes are run""
This in theory should be fixed now, sorry took so long. @fflo, it probably should be a separate issue but could you confirm TLS v1.2 is working? |
Thank you! |
Probably because the Dockerfile now uses OpenJDK 8 which should have better support for TLS 1.2 cipher suites.
|
I'm commenting specifically on the unifi5 docker file.
I docker exec'd into the running container and reviewed the declared volume folders and found the following:
/var/lib/unifi - This volume seems ok, contains MogoDB Data AND Unifi Server Logs + Settings
/var/log/unifi - This folder is empty.. Logs are contained in the previous mount.
/var/run/unifi - This folder is empty. Not sure what should/would have been here?
/usr/lib/unifi/work - This folder contains an empty folder called ROOT.. nothing else.
What's missing are the MongoDB logs... They can be found here: /usr/lib/unifi/logs/mongod.log
So I purpose we REMOVE /var/log/unifi /var/run/unifi /usr/lib/unifi/work and ADD /usr/lib/unifi/logs
So end result would be:
VOLUME ["/var/lib/unifi", "/usr/lib/unifi/logs"]
Thoughts? I'd be more than happy to submit a PR too...
The text was updated successfully, but these errors were encountered: