QtService: Segfault after fork

[wysota]

Do the examples bundled with QtService work properly?

[chenz]

This seems to be a static intitialization/race condition problem in Qt 4.7.4:

• Sometimes after I re-compile the problem goes away (this is also probably the cause why adding/removing QtGui has any effect)
• The problem goes away when I use Qt 4.7.4 compiled without glib
• It also goes away when I use Qt 4.8.0, which had some QThread race conditions fixed

[wysota]

Do the examples work?

[chenz]

The http server example shows the same behaviour.

[wysota]

In that case indeed the problem might be with Qt or Glib.

[martonmiklos]

The similar problem also affects me on Ubuntu 11.10 64 bit factory Qt 4.7.4 installed.

I would welcome any recommeddations about how should I create a Linux service using Qt with or without QtService.
Thanks!

[wysota]

With Linux it is easy since you don't need any extra treatment in the process itself to make it a daemon. The whole work is done by the init script. If you really want, you can just fork() the process to detach it from the terminal (see man daemon for more details).

[bob2oneil]

I have attempted to use the Linux API "daemon" to implement my application as a daemon. While the application runs to some extent, and can be viewed in the system manager, some of my custom threads do not seem to work.
These include an SNMP thread which makes a connection to the SNMP daemon, a TCP socket thread, etc. There are other threads which do seem to work This is for a 4.8 build dynamically linked.

Is there any particular issue with having a multithreaded Qt application work as a daemon, and specifically network related threads.

I was going to try the heavier weight QtService to see if it provides a solution.

In my application, I need to act as a daemon by default, but as a simple console application based on a command line argument.

Anyone have any thoughts or experience with either of these implementations?

[bob2oneil]

Some additional testing has revealed that none of my secondary threads run when my application is run as a daemon using the Linux "daemon" command (e.g. daemon(0, 0)), but execute without issue when the application is run as a console application. This application is a pure console application without any GUI, and uses only the Qt Core and Qt Networking libraries (version 4.8).

Is anyone aware of Qt secondary thread issues when using the Linux daemon command? Are there any workarounds?

It there any reason to believe that implementing a solution basd on QtService would fair any better?

[wysota]

Using daemon() has nothing to do with your threads. If your threads fail to work then it's likely because you're using some relative paths or something similar in your app.

[bob2oneil]

Thanks for you input. These secondary threads do not have any file system path content or issues that I am aware of. I have these secondary threads working now, and it required that the "daemon" call occur in main.cpp prior to the creation of the application object. Perhaps there is an explaination for this behavior.

[bob2oneil]

To strike a finer point on this issue, I have narrowed the problem down to a routine that I composed to detect currently running processes by process name to ensure that my application is run as a singleton.

This routine utilizes the QProcess() Qt class and invokes "pidof" to obtain a list of PIDs for a particular process name.

This appears to be problematic if invoked prior to the daemon() API call.

I am not sure why, but these are my observations under Qt 4.8 with dynamic linking.