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.
Related
I accidentally set the default systemctl target to basic target while trying to switch from multi-user to graphical target on my raspberry Pi 3B which runs the Raspbian OS. Since then when I boot my RPi it does not start and only displays a welcoming screen. I tried to edit the config and cmdline files while in recovery mode to try to access the command line but I could not. Can someone explain to me what the basic target even is because I have been searching online for hours and cannot find a proper explanation? Do I need to format my RPi now or can I access my command line by some way to switch to multi-user target?
Thanks in advance.
The documentation for all systemd so-called special units is available under systemd.special(7) man page (or in the respective online version).
basic.target is an early-boot synchronization point, ordered even before initrd, so the service for login prompts is simply not started, thus there's no command line to work with. This is nicely described and visualized in the bootup(7) man page.
You can temporarily override the default target from the kernel command line using the systemd.unit= argument (systemd(1), section Kernel Command Line).
In your case, adding systemd.unit=multi-user.target to your kernel command line should be enough to allow you to boot back into your rPi and then make the target change permanent by calling systemctl set-default multi-user.target (or graphical.target, as that seems to be the original way you were trying to follow).
In my Android Things app, I need to use su from runtime. However, Android Things system is built as userdebug build, so I can only access it from adb. I tried to both replace su binaries with no luck. I tried to disable ro.secure by unpacking and repacking boot.img, however flashed system still returns getprop ro.secure 0. How can I achieve root in my Android Things device?
I had these scripts working on a quite early preview version, maybe 0.1 or 0.2. https://github.com/fmatosqg/androidthings_ndk/tree/master/app/src/main/script
Although I had to run it manually, there should be a place where I can add this script so it runs every boot, just like linux's /etc/rc.d
I don't remember how I got the script to work, but the idea is that one script simply exists to launch the other running as superuser, similar to what you would expect with sudo <insert command here>
I have a simple application using
QT += core gui network webkitwidgets
I've used windeployqt.exe to generate the 32 bits release on my win-10 64 bit computer. When I put the folder on a win-7 64 Bit desktop and double-click the app.exe, it never starts.
I can see it in the task manager, but I can't kill it, and if I try I cannot close the explorer folder in which I double clicked anymore.
I've checked the usual platform, ICU, qwindows.dll, and so on.
http://doc.qt.io/qt-5/windows-deployment.html
EDIT Precisions:
I've compiled with default 32 Bit kit: "build-Test-Desktop_Qt_5_5_1_MinGW_32bit-Release" with "mingw492_32"
I have a package "release" generated by windeployqt.exe using the --webkit switch. I start a command prompt:
> set path=
> set mingw=
Then I make sure that no Qt/Mingw things exists anymore in my environment variables.
I also rename "c:\Qt" into "c:\ __Qt".
I move my release folder on my desktop.
I start release\test.exe ( from the clean path shell )
Everything runs fine! So The release/test.exe has everything it needs without the path/mingw variable.
But as soon as I put the folder on another windows machine ( 7 instead of 10 ) it never starts.
I tried dependency walker. It shows a lot of "API-MS-WIN*.dll" missing...
It even shows much more missing dlls on the "good" machine than on the bad one !!!
Every single "missing dll" on the "bad" target machine is actually in system32 on this machine.
Thanks for advice, every advice is welcome, I'm a bit desperate... :)
Edit
It seems to be related to the machine itself. I have successfully deployed this (very small) app to 2 non developer machine on win7 and win8 respectively. But the above "bad machine" still resits running it...
Edit
The problem seems not to be general but related to this one particular machine. Hence, feel free to close or move to the appropriate forum as it is not related to Qt/windeplyqt. If I figure out a solution, and question is closed, I'll simply add a last edit. Safe Boot and malwarebyte are my next actions.
After a long investigation.
Do not believe dependency walker, it used to be a top notch tool but it is now outdated.
If there is a missing dll, the system will prompt you with "cannot load dll xxx.dll" anyway.
Your best shot in case a soft runs on machine X but not on Machine Y is:
start in safe mode ( run: msconfig --> diagnostic startup )
turn off any antivirus or non microsoft/driver software,
"run as administrator".
If you can run with step 3. Then proceed by elimination:
run without admin rights,
Start anti spyware, etc...
Add appropriate exception to your antivirus if it is the root cause.
If the antivirus is not the root cause, run process monitor on both machines. Then compare, what Failed on one machine and not the other ? Read the windows event log and compare any error messages on both machines.
run sfc /scannow to check disk
run a complete anti spyware scan/ pc-repair tool ( malwarebytes, combofix, ... )
Make sure you really have the very same package on both machines, make sure you are not trying to run an exe on mac OS, make sure your computer is on.
Call the oracle, you are in the matrix...
In my case the problem was Avast and it was solved by adding appropriate exception.
Does anyone know a good method to debug server side code?
I tried enable Node.js debug then use node-inspector but it does not show any of my code.
I end up using console.log but this is very inefficient.
Update: I found the following procedure works on my Linux machine:
When you run Meteor, it will spawn two processes
process1: /usr/lib/meteor/bin/node /usr/lib/meteor/app/meteor/meteor.js
process2: /usr/lib/meteor/bin/node /home/paul/codes/bbtest_code/bbtest02/.meteor/local/build/main.js --keepalive
You need to send kill -s USR1 on process2
Run node-inspector and you can see your server code
On my first try, I modify the last line on meteor startup script in /usr/lib/meteor/bin/meteor to
exec "$DEV_BUNDLE/bin/node" $NODE_DEBUG "$METEOR" "$#"
and run NODE_DEBUG=--debug meteor on command prompt. This only put --debug flag on process1 so I only see meteor files on node-inspector and could not find my code.
Can someone check this on Windows and Mac machine?
In Meteor 0.5.4 this has become a lot easier:
First run the following commands from the terminal:
npm install -g node-inspector
node-inspector &
export NODE_OPTIONS='--debug-brk'
meteor
And then open http://localhost:8080 in your browser to view the node-inspector console.
Update
Since Meteor 1.0 you can just type
meteor debug
which is essentially a shortcut for the above commands, and then launch node inspector in your browser as mentioned.
Update
In Meteor 1.0.2 a console or shell has been added. It may come in handy to output variables and run commands on the server:
meteor shell
Meteor apps are Node.js apps. When running a Meteor app with the meteor [run] command, you can configure the NODE_OPTIONS environment variable to start node in debug mode.
Examples of NODE_OPTIONS environment variable values:
--debug
--debug=47977 - specify a port
--debug-brk - break on the first statement
--debug-brk=5858 - specify a port and break on the first statement
If you export NODE_OPTIONS=--debug, all meteor command run from the same shell will inherit the environment variable. Alternatively, you can enable debugging just for one run, with NODE_OPTIONS="--debug=47977" meteor.
To debug, run node-inspector in a different shell, then go to http://localhost:8080/debug?port=<the port you specified in NODE_OPTIONS>, regardless of what node-inspector tells you to run.
To start node.js in debug mode, I did it this way:
open /usr/lib/meteor/app/meteor/run.js
before
nodeOptions.push(path.join(options.bundlePath, 'main.js'));
add
nodeOptions.push('--debug');
Here are additional practical steps for your to attach debugger eclipse:
use '--debug-brk' instead of '--debug' here, because it's easier for me to attach node.js using eclipse as debugger.
add 'debugger;' in the code where you want to debug.(I prefer this way personally)
run meteor in console
attach to node.js in eclipse(V8 tools, attach to localhost:5858)
run, wait for debugger to be hit
when you start meteor in your meteor app folder, you'll see that "debugger listening on port 5858" in console.
On Meteor 1.0.3.1 (update to Sergey.Simonchik answer)
Start your server with meteor run --debug-port=<port-number>
Point browser to http://localhost:6222/debug?port=<port-number>
Where <port-number> is a port you specify.
In your code add a debugger; where you want to set your break point.
Depending on where debugger; is invoked, it will either break on your client or server browser window with inspector opened.
I like to set breakpoints via a GUI. This way I don't have to remember to remove any debugging code from my app.
This is how I managed to do it server side for my local meteor app:
meteor debug
start your app this way.
Open Chrome to the address it gives you. You MAY need to install https://github.com/node-inspector/node-inspector (it might come bundled with Meteor now? not sure)
You'll see some weird internal meteor code (not the app code you wrote). Press play to run the code. This code simply starts up your server to listen for connections.
Only after you press play you'll see a new directory in your debugger folder structure called "app". In there are your meteor project files. Set a breakpoint in there one the line you want.
Open the local address of your app. This will run your server side code and you you should be able to hit your breakpoint!
Note: you have to reopen the inspector and go through this process again each time your app restarts!
As of Meteor 1.0.2 probably the best way for server-side debugging is directly via the new built-in shell: with running server run meteor shell. More info here: https://www.meteor.com/blog/2014/12/19/meteor-102-meteor-shell
I am not sure why it was not working for you.
I am able to use it by following steps on console (Mac).
$ ps
$ kill -s USR1 *meteor_node_process_id*
$ node-inspector &
Above steps are mentioned on https://github.com/dannycoates/node-inspector. It is for attaching node-inspector to running node process.
I wrote a small meteor package called meteor-inspector which simplifies the use of node-inspector to debug meteor apps. It internally manages the lifecycle of node-inspector and hence, the user does not need to restart the debugger manually after some files have changed.
For more details and concrete usage instructions take a look at https://github.com/broth-eu/meteor-inspector.
for meteor 1.3.5.2, run
meteor debug --debug-port 5858+n
n is a non-zero number, this will cause node-inspector use 8080+n as web port.
WebStorm, the powerful IDE free for open source developers, makes it much easier to debug server-side.
I've tested it on Windows, and the configuration was painless - see my answer.
A inspector that solve my issues is meteor server console. Here is the process I followed to install it:
In your project folder, add the smart package server-eval:
mrt add server-eval
For Meteor 1.0:
meteor add gandev:server-eval
Restart meteor.
Download crx Chrome extension file from here.
Open extensions page in Chrome and drag crx file to extensions page.
Restart Chrome.
Check the web inspector out to eval server side code:
In comparison with node-inspector, I have a clearer output.
If you prefer to use nodeJS' official debugger you can call NODE_OPTIONS='--debug' meteor and then (on a different shell) node debug localhost:5858.
Using OpenJDK 7 from the command line on OS X Lion, how can I use jdb to debug an application that requires execution under a 32-bit JVM, due to JNI native code?
I know I can invoke java as java -d32 and it will use a 32-bit JVM. I can also pass that -d32 flag to jdb without an error, but it does not seem to have any effect: I still get the same error messages when the application tries to link its native code. Passing -J-d32 exhibits the same behaviour.
It is possible to achieve the above by starting java and jdb as separate processes from two different Terminal windows. So execute these commands, each in its own window:
java -d32 -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=127.0.0.1:5463 -classpath . MainClass
jdb -attach 127.0.0.1:5463
The first will start the JVM for the application, but suspend it immediately after creation. The second will start the debugger and attach it to the JVm just created. Then you can type run in that second window to launch the application. As an added bonus, output from the application and the debugger are not intermixed, as each has its own window.
References: The jdb help lists possible command line arguments, and JPDA has a section on transports.
Although the above does work for me, I'd welcome other answers providing easier solutions, preferrably as a single command and/or without any need to choose port numbers in an arbitrary fashion. The shared memory connector does not seem to work for my JVM.