Disable logging to file in Settings

[drws]

The problem

Vorta currently logs to a dedicated file. Sometimes that might not be the preferred solution.

Requested Solution

An option to switch logging output to user''s journald.

Alternatives

None that I know of.

[real-yfprojects]

I think supporting all kinds of logging services might be to much effort. I would be better to provide some kind of interface that easily allows to extend Vorta with different log consumers. Then you could implement a custom consumer that passes the logs to journald.

None that I know of.

Is there no way to include arbitrary log files in journald?

[m3nu]

If you run Vorta via Systemd, the logs (console output) will be in Journald. That's totally doable and you can monitor or manage the process. Very common with e.g. Borgmatic.

You can't "import" random files.

[drws]

@m3nu

If you run Vorta via Systemd, the logs (console output) will be in Journald.

Yes, but it will additionally also write into ~/.local/state/Vorta/log/vorta.log and ~/.cache/Vorta/log/vorta.log, which I'd like to avoid. The issue is about redirecting the log output somewhere else.

@real-yfprojects

I think supporting all kinds of logging services might be to much effort.

I know systemd/journald has its own quirks, but I wouldn't count the most widespread journalling daemon (journald), backward-compatible with previously most-spread one (syslog), as all kinds of logging services. The state of the fact is that Vorta doesn't support any logging daemon.

I would be better to provide some kind of interface that easily allows to extend Vorta with different log consumers.

While it would've been great to have a standardized interface, that is not Vorta's task to solve. The scope of this issue is to support only the most standardized one available - journald. Additionally, I'm a bit late to emphasize that we are talking about journald --user, which not all logging daemons even support.

However, there's an option to use a third-party library for the task (that supported as many daemons as possible). I think I saw something like that in the past, but it seems I haven't bookmarked it.

Then you could implement a custom consumer that passes the logs to journald.

That's two feature requests ahead, but of course it would also be good to have that feature.

Is there no way to include arbitrary log files in journald?

The too-lightly-emphasized point is that I don't want arbitrary hardcoded log files just lying around /home, so this is unfortunately not a solution. For example, journald supports system-wide logging to RAM with a single configuration line (to spare /home write cycles).

And also: I'm running pleothra of software and basically everything else already behaves and logs with journald/journald --user, Vorta really is sticking out.

[m3nu]

As a multi-platform app we use the lowest common denominator, which are simple files.

I don't see us adding different logging frameworks, since it's mostly used for debugging right now. But there could be a setting to disable logging to files (default: enabled). Then you can capture them via Systemd only, if you really want.

[drws]

Ok, fair enough. Disabling log files is still a solution. However:

• Does Vorta echo all output that is also present in both log files?
• This FR remains open. Do we repurpose it or open a new one?
• What about an additional/auxiliary .service file? There is some talk in #1583, but I can't seem to find related FRs/issues.

[m3nu]

Yes, console out put and log files are the same from the same Python logging source.

If you come up with a suitable .service file, we can add it to the docs under the Linux install instructions.

[AdwaitSalankar]

Hi @m3nu, does this look good?

[drws]

The inverted-logic approach is needlessly confusing. Please make it a simple "Enable logging to file" and ticked/checked by default.

[shivansh02]

@AdwaitSalankar are you working on this?

[AdwaitSalankar]

@shivansh02 Yes, I am close to opening a PR.