1

I have a custom xinetd server process that formerly worked, but it now generates errors when dconf warning messages are printed into the output stream. I think it is a configuration issue, but I can't figure out how to resolve it. I am getting the same issue on multiple machines (that all run flavors of Ubuntu 17.04). It worked until an upgrade earlier in the year.

The following message text appears in the output stream:

(process:13179): dconf-WARNING **: failed to commit changes to dconf: Cannot
autolaunch D-Bus without X11 $DISPLAY

A little bit of background information:

An xinetd server process simply writes to stdout and reads from stdin, which xinetd redirects to a port. It's great because xinetd does the lower-level communication. But xinetd doesn't set up all the user context information. For that reason, I have a shell script that sets up this information. Here is what the shell script looks like.

#!/bin/sh

export USER=erik
export HOME=/home/$USER
#export DISPLAY=':0'

. $HOME/.bashrc
. $HOME/.postm/bin/additions.txt

cd $HOME
runserver

The final command runserver is a custom HTTP server process that reads stdin and writes to stdout. I am able to run it from the terminal and manually enter requests and get responses without generating errors or warning messages.

Notice that one of the lines has been commented out. When I uncomment that line:

export DISPLAY=':0'

The process takes longer to respond, and then I get the following error:

(process:14160): dconf-WARNING **: failed to commit changes to dconf: Could
not connect: Connection refused

There is a blank line before these errors and warnings, which causes them to be written into the text of the user's web page. This confuses Firefox.

Since the process works fine from the terminal and fails in the xinetd context, I believe it's because dconf is getting confused that the process is now running within xinetd. This should be a resolvable configuration issue, but I have tried a lot of things and I'm still stuck.

If anyone has advice for how to keep these warning or error messages from appearing in my server output stream, I'd be grateful.

0

This is resolved. The original script was sourcing a shell script that has a gsettings statement in it, which was not intended to run in a server context. Simply removing that statement has resolved the problem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.