vorta --create crashes if DISPLAY not available

[drws]

trafficstars

Describe the bug

When vorta --create is ran from a shell where $DISPLAY isn't available it goes into an uncontrolled Qt5-related crash instead of complaining or trying to find the value of DISPLAY itself.

To Reproduce

> unset DISPLAY
> vorta --create "$VORTA_PROFILE"
qt.qpa.xcb: could not connect to display 
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.

Aborted (core dumped)

Environment (please complete the following information):

• OS: Arch Linux
• Vorta version: 0.8.7
• Installed from: OS repository

[real-yfprojects]

Vorta is a desktop application. What is your use case for having to run vorta without a display?

[drws]

I know and use it so, but vorta --create is a part of (albeit small) Vorta CLI. The device does have a screen, just the DISPLAY variable is not directly accessible from the environment it is ran in. I'm trying to trigger a backup from a background (NetworkManager-dispatcher) script.

[real-yfprojects]

QT, the GUI framework vorta uses, will be loaded on startup and crashes immediately. Currently there is nothing we can do about that. You will have to work around the problem by setting DISPLAY in the script yourself.

[drws]

I did work around it by manual setting, but there is still much more that Vorta could do in such case:

1. Vorta could get the value somehow since it has the necessary privileges. If not directly then a CLI invocation could still get $DISPLAY from a very-likely running Vorta service (which should have it for displaying sthe GUI anyway).

2. Even if the value cannot be obtained sometimes, Vorta shouldn't crash, but rather detect the situation, warn the user accordingly and make a controlled exit.

Since crashing is probably not the desired behavior anytime, please rethink the invalid status. The part with obtaining the DISPLAY is a feature request and can be spun off to a separate issue if necessary.

[real-yfprojects]

When importing the main component of Qt the whole process will crash without rasing an exception. Therefore there is no pythonic way of preventing a crash besides checking the DISPLAY variable before hand. This however would be the beginning of checking al kinds of environment attributes that might crash Qt. Maintaining such a list of checks is unreasonable in my opinion.

What do you think @m3nu?

[m3nu]

Totally agree. Vorta relies on a working Qt installation.

[drws]

Ok, I see this is solely a Qt issue. Would you be so kind to direct me to the proper repository for a version that currently is or will be in the near future used with Vorta?

[real-yfprojects]

Vorta supports recent versions of Qt5. You can find more information on qt.io. They also have a bug tracker.

[drws]

It seems that the crash occurs in Qt5 and Qt6 while PyQt doesn't matter. I've reported it to Qt bugtracker where it belongs.

There is another question about the issue - that vorta --create shouldn't need GUI libraries at all. @real-yfprojects, you've written that

QT, the GUI framework vorta uses, will be loaded on startup and crashes immediately.

But none of Vorta CLI commands really needs Qt, except for maybe --daemonize. @m3nu Why would the Qt be loaded if one runs vorta --help or vorta --version? Seems like an unnecessary complication. The same goes for vorta --create. Its description even says:

Vorta must already be running for this to work.

So the Qt is already loaded when vorta --create is called. It just needs to make a relevant IPC call to the main Vorta process (which needs and already includes Qt) - and that's it. Loading and executing tens of megabytes of GUI libraries for a second time is not only slow and redundant, but also counterproductive in case of a CLI execution.

Yes, Vorta's CLI is currently very small, but that's no reason that it shouldn't be done well. Even:

Vorta is a desktop application. What is your use case for having to run vorta without a display?

Nowadays even some desktop applications make use of WebUI instead of a real GUI, especially service-type programs such as Vorta. While I'm not fan of the approach for local interaction, it is very useful for remote operations. Properly prepared codebase with modularized interfaces (a proper separation between CLI and GUI) would be a good starting point should someone need and implement a WebUI for Vorta.

[real-yfprojects]

I totally aggree @drw. But currently we have to work with what we have. Though there is #1076 which is waiting for input.