Hi
I wrote a console application that runs as a linux daemon. It receives requests via at TCP socket and prints the requested form using SVG. However, it only works when I am logged into the Linux PC. I need it to run as a service without any user logged in. When I try to run it as a service without a user logged in I get the “cannot open display:0” error.
What do I need to do to get this to work with and without a user logged into the PC? I have included the unit file of the service. I am running on Opensuse Leap 15.1
Can you please include the line with the prompt and the command before the output (and the line with the new propmt after the output in your CODE posts. Only so can other see what you did and more (often working directory, user). It is so easy to do and so important to have. In this case it would start with the line with the cat command.
I am not sure what you are trying to do, (no idea what /home/remote/KardTech/FusionPro/dcfusngardian is), but the fact that you add a value to DISPLAY in the environment hints to a GUI based program. And that will of course never work when nobody is loged in.
For a start, your custom service is likely started too early, and would require AFTER=<suitable target>, and possibly an small delay with the sleep command as well. However, if there are no users logged in (you don’t have desktop autologin enabled I asume), then I’m wondering what is the purpose of your console application? Maybe there is a better way here?
The purpose of the console app is as described above to print a form when a request is received on a socket. The console app does not have a GUI as it runs as a daemon listening on a TCP port. When it receives a request it sends the requested form to the default printer. The problem is that SVG library will not run unless it detects a display even though the display will never be used.
I have thought of creating a specific autologin user just for the purpose of running the daemon. In that case I still need to find the correct DISPLAY variable to add to dCFusnGardian.service unit file.
The unit file above runs just fine when I login as remote. The dCFusnGardian is the actual daemon and it runs fine. Its job is to ensure a number of console apps are always running of which there a 4. Three of them are working perfectly and have done so for months. The problem is with the new console app for printing forms. The output device for the SVG drawing is the default printer but the graphics library checks for a display at start up despite the fact it will never be used thus the error message that started this thread. The new console app will not start if a user is not logged in. Once a user is logged in it runs perfectly.
xauthority in many cases would address any authentication issues.
Approaching these tasks…
I’d first ask if those apps can run without a graphical display. Many if not most can do so which would then make any display requirement moot.
I think also that you should be more concerned with what session the apps are running in, and only because some apps may be graphical apps they could be associated with a Display.
There is a bit of confusion by saying that the apps should be running regardless whether a User is logged in. AFAIK a session can run without a Display but a Display is reserved only when a session is running. Possibly tied to whether your apps can run in non-graphical mode, would determine if you can set for “headless” (no user logged in a physical keyboard and display).
Naturally a daemon should not usually be tied to a specific display or session, it would normally run as a system service.
I would like to be clear that none of the applications require a graphical display. The problem is that the Linux library used for printing is causing the issue. From what others who have come across this problem have said is that the library checks for a display when it is first loaded and will not load unless it finds a display even though the display will never be used.
Yes you are correct. It solved the immediate problem of get my service to run properly but has not yet solved the problem in the library that causes the problem.
