I've noticed that in the latest version of xsbt the jetty container gets forked and passing system properties no longer works.
I was looking for a simple way to pass a port number via system property when launching sbt in order to set the port for the jetty container. It's not clear if this is possible or not.
Also, I'm running into a problem for local development because it is impossible to pass options to the container now. I'm not sure how to change out settings quickly and conveniently without being able to do this. Is there a reason that the forked java process can't inherit or be passed the system props?
Also just curious what the reason is for needing the container to run in a forked process in the first place.
I've noticed that in the latest version of xsbt the jetty container
gets forked and passing system properties no longer works.
To pass JVM system properties to the forked process, you can use either the containerForkOptions setting:
containerForkOptions := new ForkOptions(runJVMOptions = Seq("-Dh2g2=42"))
Or you can use javaOptions in Jetty:
javaOptions in Jetty += "-Dh2g2=42"
I was looking for a simple way to pass a port number via system
property when launching sbt in order to set the port for the jetty
container. It's not clear if this is possible or not.
There are a couple ways to do this. You can use the containerPort setting:
containerPort := 9090
Or you can pass arguments directly to jetty-runner:
containerArgs := Seq("--port", "9090")
Also just curious what the reason is for needing the container to run
in a forked process in the first place.
See https://github.com/earldouglas/xsbt-web-plugin/issues/136
Related
I have a GUI application which contains a websocket server QWebSocketServer. I also have a python script which sends messages and the application processes them. Everything works well. During testing I wanted to run the application in headless mode using -platform offscreen command line argument added to the app executable name (I changed nothing else). But the problem is that when the application runs off-screen, the client script cannot establish connection with the web socket server. I tested this on localhost only. I do not understand how this two things, visibility of GUI and websockets, can interfere. Any ideas what could go wrong?
Note: I am using Qt 5.11.1 64-bit with VS 2017 on Windows 10 Pro.
A platform plugin is a bit more than merely "GUI". The -platform option selects a family of platform-specific plugins. Perhaps some plugins that make networking work are absent on that platform spec. That's very likely, since the offscreen platform is only a proof-of-concept: it's to show how you'd write a platform plugin. It's example code, and it does the bare minimum needed. It's nothing that you should be using for production without fully understanding what's there and how it works - it wasn't not meant for it, at least not the last time I looked at it. It shouldn't be hard to make it work, but you'd need to clone the source and start hacking on it.
I want to use gitLab-CI for a Qt-project, but i can't figure out, what I need to do so. I understand, that the whole pipeline process takes place on the CI-Server, but how do I setup the needed requirements like the qt-environment?
Solution:
Ok now I got it! You just use the Runner for it, if you do not have a Server, you can use a VM.
For GitLab.com
The runners are already set up (shared runners).
You need to use a Qt SDK Docker image or install it yourself:
Use image: <image-name> for .gitlab-ci.yml
Use apt or some other package manager (not recommended)
Once you got a Qt SDK environment set up inside .gitlab-ci.yml, make sure to add a command to build/compile/run/test it.
For non-GitLab.com
The runners may or may not be set up, but you do not need to do any specific changes (other than using faster machines with bigger memory, etc for building in necessary).
You need to use a Qt SDK Docker image or install it yourself:
Use image: <image-name> for .gitlab-ci.yml
Use apt or some other package manager (not recommended)
Once you got a Qt SDK environment set up inside .gitlab-ci.yml, make sure to add a command to build/compile/run/test it.
Other Helpful Comments
This is from Josh Peak's comment:
Ok that answers my question. I'm going to have to preconfigure a VM image and/or a Docker image with the QT SDK that the rest of my dev team can leverage. Thanks for the quick response.
This answer is from ManuelP.'s question:
Ok now I got it! You just use the Runner for it, if you do not have a Server, you can use a VM.
I've run into an issue with Saltstack version 2014.7.0, where I cannot get network information from Salt.
If I run:
salt-call network.ip_addrs
I get:
Function network.ip_addrs is not available
This only seems to happen on some of my hosts. It seems to effect the almost all of the functions in salt.modules.network, but everything else works as expected.
I suspect there's something in my environment to blame. I am running salt within a CentOS 7 docker container. I followed these instructions to get Systemd running under Docker, and it seems to be functioning just fine, so I don't think that's the issue, but I wouldn't be surprised if it's related. I'm using Docker as a development environment, but I will be using these formula to orchestrate virtual machines in production.
Has anyone encountered the network module not being loaded properly? Is there something that needs to be available for that module to be accessible?
I have other mechanisms to get the IP address, but none that are as easy to work with in other salt formulas.
It turns out my problem was that I had my own custom module called "network" which was obscuring the upstream network module.
I'm pretty sure this was working at some point in the past, so I'm wondering if there might have been a change to salt in a more recent version that would cause it to conflict at a module level instead of merging methods from different modules of the same name, but I suppose it's possible that it never worked.
I've developed a Qt application which contains a TCP server and such. I'm now trying to make Ubuntu packages and let the application automatically start on startup.
The application needs to be running even if nobody is logged in, which means a daemon started via a script in /etc/init.d/
I tried simply running the application on start and sending a kill-signal on stop in the init.d script but that means the application runs in the foreground and blocks the init-script.
Forking like in an other question almost seems to work, I get 'unknown error' after trying to start a TCP server. Nevertheless, there should be an easy to way to write a init-script that runs my application in the background on startup on the various Linux distributions.
Could anyone point me in the right direction?
Using Ubuntu 9.10 with Qt 4.5
The best way is probably to use QtService where the work of forking is taken care of for you.
However, if you want to continue to build your own, you should either background the application or run it via start-stop-daemon that comes with OpenRC or a similar utility for your distribution.
Also, make sure that you only link to the QtCore shared library. Although the application might be command line and never pull up the GUI, that doesn't mean that X isn't required in order for the application to run. For example, a set of unit tests:
$ ldd runTests | grep Qt
libQtTest.so.4 => /usr/lib/qt4/libQtTest.so.4 (0x00007fd424de9000)
libQtXml.so.4 => /usr/lib/qt4/libQtXml.so.4 (0x00007fd424baa000)
libQtGui.so.4 => /usr/lib/qt4/libQtGui.so.4 (0x00007fd4240db000)
libQtCore.so.4 => /usr/lib/qt4/libQtCore.so.4 (0x00007fd422644000)
Because QtGui is present, all the X libraries are also brought in, although filtered from the above output.
Is your program a GUI application or does it work without GUI?
Why don't you just background it within the init script using &?
You need to add a symbolic link into any of the rc?.d directories under /etc depending on the default runlevel. Or use the update-rc.d script: first you need to create a script into /etc/init.d that executes the application; second, use the update-rc.d script to add the needed files to start.
You can find information about how to do it by reading update-rc.d manual page:
$man update-rc.d
I think the simplest way is to not have any daemonize logic in your application itself, instead use a helper program to start the app in the background and manage a pid for it.
For example, startproc.
You can take a look at the many scripts already in your /etc/init.d for inspiration. From what I see there, most of standard linux daemons depend on startproc for start, and killproc for stopping.
Some of my builds and plugins make use of private deployment credentials (sometimes read from the file system, sometimes entered and retained in memory via the InteractionService).
Though perhaps it is overparanoid, I try to be careful to minimize the attack surface of software that uses private information, and it feels like bad hygiene to run a server, even on localhost or a UNIX socket, unnecessarily in these builds.
I've looked for a setting I could set in a plugin that would disable server startup unless overridden by the build. So far have not found anything like this. Is there such a setting?
Many thanks!
Update: With the help of Eugene Yokota, as of sbt 1.1.1 there is now a boolean autoStartServer setting. Builds and plugins can prevent the server from starting up automatically by setting autoStartServer := false. (Users can still manually start-up the server by running startServer if they wish.)
As of sbt 1.1.0 at least, the server won't start unless you start the sbt shell, which means that if you're running sbt in batch mode (for example sbt test) in CI environment, it won't have server.
To stop server even in the shell automatically, I've added a JVM flag sbt.server.autostart. So running sbt as sbt -Dsbt.server.autostart=false would do it. You can globally set that by putting that into your SBT_OPTS.
To manually opt-in for server, you can then run:
> startServer
Update: Now that autoStartServer is a setting, you can write the following in ~/.sbt/1.0/global.sbt:
// This is so it works on sbt 1.x prior to 1.1.1
SettingKey[Boolean]("autoStartServer", "") := false