ANSWERED "Instance of eddie is already running" on Artix with runit - PLEASE HELP

[niecoinny 0]

I'm using Artix with runit init. I autostart Eddie-ui using *.desktop file in /etc/xdg/autorun at gnome login. Few times it worked, now it shows error: "Instance of eddie is already running". Manual start also fails. There is no eddie process anywhere runnning. Reinstall doesn't help. I use eddie-ui from AUR. I would like to run Airvpn-suite from AUR, but i see that AUR script has some systemd commands. Is it possible to run easily Airvpn-suite on non-systemd systems? How to fix Eddie on my system? Eddie is NOT running, yet I have this error. There are similiar threads here, but with opvn error. Nothing from those trhreads applies here. I have "eddie running", not "openvpn running" error, nothing from those topics help in my case.

Edited ... by niecoinny

[OpenSourcerer 1435]

Try AirVPN's install script, although I think it only supports Systemd and SysVinit.
As Systemd is the only init Arch Linux officially supports, my PKGBUILDS are made with the official system in mind. I do not test them on derivatives like Manjaro or Artix. But maybe someone else can create one for runit, OpenRC and SysVinit.

[niecoinny 0]

Ok. But what about Eddie-ui? It worked fine without systemd, it even autostarted with that /etc/xdg/autrun .desktop file. And it stopped working with that "Instance of eddie is already running" error. I cannot kill it, because it's NOT running. What to do? I would need systemd service only to automate elevation, but I can type password every time eddie starts. Eddie works finr without systemd. Or WORKED fine.

Edited ... by niecoinny
More explanation.

[OpenSourcerer 1435]

Tried a reboot?

[niecoinny 0]

I tried everything, including 100 reboots and pacman -Rns uninstalls. For my taste (I'm not extremely advanced linux user) it looks there is some file like asdf.lock present from not quite proper shutdown of eddie client and it thinks that eddie is running. How to remove all config files?

[OpenSourcerer 1435]

There's only one, in ~/.config/Eddie/default.profile. But that shouldn't cause the problem you're facing…
Are there any Mono processes running? If not, try contacting support via ticket, please.

[niecoinny 0]

No mono process running either. It fixed itself, but only after starting eddie-ui from terminal. Strange. I usually start eddie from UI shortcut and only this way of starting eddie shows error. I had problems like this on Windows. Eddie freaks out when it's not properly disconnected before shutdown. I ususally forcefuly shutdown eddie with system shutdown. Strange. Is there a way to  make eddie nicely shutdown at system shutdown? Even if eddie starts after 'improper' shutdown it usually throws errors. How to make eddie shutdown nicely, so it doesn't complain at startup, but without shutting down program manually?

Edited ... by niecoinny
clarification

[OpenSourcerer 1435]

4 hours ago, niecoinny said:

How to make eddie shutdown nicely, so it doesn't complain at startup, but without shutting down program manually?

I think it boils down to Systemd process termination behavior. The default is SIGTERM sent to all user processes, followed by a SIGKILL after a timeout. Eddie's closing confirmation dialog does not play well with that because, well, it expects the user to confirm the termination. This will never happen as Systemd likely terminated desktop-related processes already at this point, leaving Systemd no choice but to SIGKILL it, leading to a dirty termination, probably causing the problem you're facing. Try disabling it in Preferences > UI > Exit confirmation prompt. There may also be a possibility to raise the SIGTERM timeout for this particular process/service to give Eddie a bit more time for cleanup, but it needs research. This is for Linux.

For Windows the dirty shutdown might be of very similar origin. I needed a bit of research into how the shutdown process works on Windows. But I can safely assume the confirmation dialog is there because Windows sends a WM_QUERYENDSESSION signal to all (let's call them GUI) applications before terminating them, and the dialog prevents that effectively (with the words These processes prevent Windows from shutting down). It was not made for Linux as there is no such signal.
After getting a TRUE back from all processes' responses to this signal (indicating nothing is blocking, basically) the responsible shutdown process calls WM_ENDSESSION directly after it which seems to be functionally more or less a SIGTERM on Linux.

The thing is: There is a timeout defined lasting 5 seconds. But what I found interesting is that Windows does not reap processes just like that after it expires (as in, kill processes like a SIGKILL), it actually waits for the processes' threads to exit, which can result in Windows never shutting down if something is truly taking forever to terminate (you will see a message like Waiting for programs to end or something). Theory: What if Eddie tries to reverse something but can't because some high-level API is not callable anymore, like the Windows Filtering Platform, and we don't see any log output and therefore errors because we're already too deep into the shutdown progress? Maybe that's why Eddie thinks it must do a Recovery. Unexpected crash? after what looks like a fairly normal, boring shutdown.

[niecoinny 0]

Thanks. It helped on Windows (unchecking 'confirmation on exit' in settings), no errors after reboot and autostart. It works now, but I've done that on Windows in earlier versions of Eddie and it didn't help. But now it works I'll see how it goes on Linux (unchecking asking for confirmation on exit).

[niecoinny 0]

Still It would be nice if someone nice had Runit skills and created, or at least helped creating daemon for not asking password to elevate privileges on autostart of eddie. I need it for non-systemd Arch (Artix) and AUR. I can upload it later to AUR. There are only few runit scripts on AUR in general. It would be nice if devs would think of non-systemd users and created at least one standardized alternative way to manage services needed by program for all alternative init systems. One for systemd, and ONE for all others. I, for instance, use Runit, because I always have problems on my system with shutting down systemd (waiting minutes to finish). Doen't matter what distro. Probably there is a remedy for that, but Runit is great, it even looks better at startup . And it's faster.

[OpenSourcerer 1435]

3 hours ago, niecoinny said:

It would be nice if devs would think of non-systemd users and created at least one standardized alternative way to manage services needed by program for all alternative init systems.

As the mail in the mailing list outlines (see my link way up top), supporting just one more init system leads to a multitude of more packages and more requirements on maintainment, such as bug tracking. You'd need more contributors to handle it, but human resources are very finite resources, especially in open projects like Arch Linux. AUR packages are at the mercy of voluntariness as well. This means: Someone can take some time to create OpenRC packages but that does not mean that someone will take even more time to maintain it, as in, continuously making it work with newer versions of official Arch packages.
 

4 hours ago, niecoinny said:

One for systemd, and ONE for all others. I, for instance, use Runit, because I always have problems on my system with shutting down systemd (waiting minutes to finish).

This actually showcases the exact problem: You use runit. Someone wants SysVinit. Some want OpenRC. Mr. Ubuntulover12345 fell in love with Upstart. Four other init systems already, incompatible between each other. Now you need to not only handle the case of Systemd being installed (so to provide unit files) but also init.d scripts and OpenRC scripts, and… and… and. You see, it gets exponentially more complicated making sure everyone is fed.
You may or may not notice that I share Arch Linux's decision for supporting only a single init system. It makes my life as someone writing PKGBUILDs for Arch a tad easier, because I don't need a VM with OpenRC, one with runit and one with SysVinit to test my PKGBUILD on. I think Arch Linux had the same thought, and contributed to the immense popularity of Arch and its User Repo in general.
 

4 hours ago, niecoinny said:

Probably there is a remedy for that, but Runit is great, it even looks better at startup . And it's faster. 

Next problem:
NO. Systemd is better. #fightme

[niecoinny 0]

Still, I unchecked in linux eddie client 'confirmation on exit' and I get same error "eddie is running" at next startup. Starting from gui shorcut from gnome always fails, but running eddie-ui from console fixes all issues (until restart, that is). How it comes that using gui shortcut produces different result than using terminal to start application? I don't know if systemd is better :). On runit I've got always consistent (and noticeably quicker) boot up and shutdown times with Arch configured almost in the same way as systemd version. I'm only testing runit, but it looks nice so far. I am no programmer, but you don't have to use systemd services to start a daemon. Pipewire for ex. can run as a systemd service, but putting shortcuts in /etc/xdg/autorun works flawlesly. I bet there are many ways to start a 'service' that work on most systems and not use systemd-specific commands. I don't know. Maybe not. As I said, I'm no programmer.

[OpenSourcerer 1435]

14 hours ago, niecoinny said:

Starting from gui shorcut from gnome always fails, but running eddie-ui from console fixes all issues (until restart, that is). How it comes that using gui shortcut produces different result than using terminal to start application?

Could be different command line. Can you post the contents of the .desktop file?
 

14 hours ago, niecoinny said:

I don't know if systemd is better :). On runit I've got always consistent (and noticeably quicker) boot up and shutdown times with Arch configured almost in the same way as systemd version. I'm only testing runit, but it looks nice so far. I am no programmer, but you don't have to use systemd services to start a daemon. Pipewire for ex. can run as a systemd service, but putting shortcuts in /etc/xdg/autorun works flawlesly. I bet there are many ways to start a 'service' that work on most systems and not use systemd-specific commands. I don't know. Maybe not. As I said, I'm no programmer.

 

Quote

William, do you notice something? Or rather, do you notice something that's not there to be noticed?
  ~ Jack Sparrow

.

[niecoinny 0]

.Desktop for eddie from /usr/share/applications:

[Desktop Entry]
Name=Eddie - OpenVPN GUI
Comment=OpenVPN UI
Exec=/usr/bin/eddie-ui
Icon=/usr/share/pixmaps/eddie-ui.png
Terminal=false
Type=Application
Categories=GNOME;Network

X-Desktop-File-Install-Version=0.26

I start Eddie from terminal simply typing eddie-ui. Strange.

I didn't get that Jack Sparrow thing Runit on some systems start almost 2x faster than similiar systemd, or even OpenRC config. That's undeniably a nice thing.

[OpenSourcerer 1435]

11 hours ago, niecoinny said:

Terminal=false

Set to true for debug purposes. This opens a terminal and executes /usr/bin/eddie-ui, should be very similar, if not the same, to calling eddie-ui in your own terminal.
 

11 hours ago, niecoinny said:

I didn't get that Jack Sparrow thing Runit on some systems start almost 2x faster than similiar systemd, or even OpenRC config. That's undeniably a nice thing.

Shame. If you got it, you would've stopped the discussion already, but here you are.

[Staff 9972]

@niecoinny
@OpenSourcerer

Some info that might come handy for the current discussion as well as for future reference (Linux only).

Various systemd versions currently used in the majority of Linux distributions, are affected by a severe bug. When the bug comes out, at the proper termination of a unit, systemd sends SIGTERM immediately followed by two SIGKILL signals, without respecting the timeout.  The bug affects at least the following versions: 204, 215, 234, 246, 248 therefore most (all?) Linux-systemd distributions are involved.

When the bug comes out (frequently in 204 and 215, sometimes in 234, very frequently/always in 246, under investigation in 248) Eddie can't restore DNS settings and firewall rules (of course), and the same will happen with Bluetit (a real daemon included in the AirVPN Suite). Next unit files for Bluetit will include the only known (so far) workaround for this problem, i.e. directive SendSIGKILL=no.

You can find hundreds of web pages reporting the bug in details in years, in the bug tracker too, but unfortunately a definitive fix has not yet come out. Example which summarizes well the problem:
https://groups.google.com/g/weewx-user/c/Yg8OJ7uot7U

@niecoinny

It's worth testing AirVPN Suite in Linux, if you have time. We're also very glad to know that you managed to run Eddie properly with runit after some effort In this case, the various problems caused by systemd should vanish.

On the other hand, while Eddie remains a system process, Bluetit is a real daemon. Out of the box the installer supports systemd and various SysVInit-like systems, but it's untested in your specific environment, so let us know whether you decide to test it (if so, go directly with 1.1.0 RC 4 - 1.1.0 release is imminent).

Even if your init system can't be handled by the installer, you can treat Bluetit according to your needs easily. Since it is a real daemon it should be possible to handle it classically in most init systems with no peculiar problem.
https://airvpn.org/forums/topic/49247-linux-airvpn-suite-110-beta-available/

Are you running runit as a supervisor of some SysVinit-like system or are you using it as a total drop-in replacement for init?

Your decision to avoid systemd is in our opinion very wise. systemd is much appreciated by many people coming from Windows because it replicates some Windows concepts but betrays the basic UNIX philosophy and never you have seen such a monstrosity in, for example, the vastly superior FreeBSD (where, instead, you can find even runit).

And yes, with runit you should achieve under many circumstances (bootstrap for example) higher performance than with systemd and you remain safe from the interference at many system levels of systemd  (which is not only an init system). Keep us posted if you test!

 Kind regards
 

[niecoinny 0]

I use runnit exclusively. Is runnit supported by AirVpn Suite installer? I have nothing against testing AirVPN Suite :).

[OpenSourcerer 1435]

@Staff, the magic is that I encountered exactly this yesterday when I tested suite v1.1 but trying to reproduce it today does not show this behavior. Systemd v248.3-2-arch

Jun 04 20:20:59 systemd[1]: Starting AirVPN Bluetit Daemon...
Jun 04 20:20:59 bluetit[106311]: Starting Bluetit - AirVPN OpenVPN 3 Service 1.1.0 - 4 June 2021
Jun 04 20:20:59 bluetit[106311]: OpenVPN core 3.7 AirVPN linux x86_64 64-bit
...skipping...
Jun 04 21:32:51 bluetit[178097]: Received SIGTERM signal. Terminating Bluetit.
Jun 04 21:32:51 bluetit[178097]: AirVPN Manifest updater thread finished
Jun 04 21:32:51 systemd[1]: bluetit.service: Killing process 178097 (bluetit) with signal SIGKILL.
Jun 04 21:32:51 bluetit[178097]: Received SIGTERM signal. Terminating Bluetit.
Jun 04 21:32:51 systemd[1]: bluetit.service: Killing process 178097 (bluetit) with signal SIGKILL.
Jun 04 21:32:51 systemd[1]: bluetit.service: Deactivated successfully.
Jun 04 21:32:51 systemd[1]: bluetit.service: Unit process 178097 (bluetit) remains running after unit stopped.
Jun 04 21:32:51 systemd[1]: Stopped AirVPN Bluetit Daemon.
  [ this was not a shutdown ]
-- Boot 8376f206ac384996b0b0e90eca88907a --
Jun 05 10:30:04 systemd[1]: Starting AirVPN Bluetit Daemon...
Jun 05 10:30:04 bluetit[55017]: Starting Bluetit - AirVPN OpenVPN 3 Service 1.0.0 - 7 January 2021
Jun 05 10:30:04 bluetit[55017]: OpenVPN core 3.7 AirVPN linux x86_64 64-bit
Jun 05 10:30:04 bluetit[55017]: Copyright (C) 2012-2020 OpenVPN Inc. All rights reserved.
Jun 05 10:30:04 bluetit[55019]: Bluetit daemon started with PID 55019
Jun 05 10:30:04 bluetit[55019]: Successfully connected to D-Bus
Jun 05 10:30:04 bluetit[55019]: Reading run control directives from file /etc/airvpn/bluetit.rc
Jun 05 10:30:04 bluetit[55019]: IPv6 is  available in this system
Jun 05 10:30:04 bluetit[55019]: Bluetit successfully initialized and ready
Jun 05 10:30:04 systemd[1]: Started AirVPN Bluetit Daemon.
Jun 05 10:30:04 bluetit[55019]: AirVPN Manifest updater thread started
Jun 05 10:30:04 bluetit[55019]: AirVPN Manifest update interval is 15 minutes
Jun 05 10:30:04 bluetit[55019]: Updating AirVPN Manifest
Jun 05 10:30:05 bluetit[55019]: AirVPN Manifest successfully retrieved from server
Jun 05 10:30:25 systemd[1]: Stopping AirVPN Bluetit Daemon...
Jun 05 10:30:25 bluetit[55019]: Received SIGTERM signal. Terminating Bluetit.
Jun 05 10:30:25 bluetit[55019]: AirVPN Manifest updater thread finished
Jun 05 10:30:25 systemd[1]: bluetit.service: Deactivated successfully.
Jun 05 10:30:25 systemd[1]: Stopped AirVPN Bluetit Daemon.

.

[Staff 9972]

@OpenSourcerer

Thanks! Something might have changed in 248 because we can't reproduce the bug with the reliability we had in all previous versions we tested (205-->246).

But you just proved that the bug is still there, unfortunately. Note how systemd first did not respect the timeout between SIGTERM and SIGKILL, and then sent twice SIGKILL (SIGTERM, SIGKILL and SIGKILL are all sent, according to our tests, in a time not greater than 0.2 s).

Kind regards
 

[Staff 9972]

13 hours ago, niecoinny said:

I use runnit exclusively. Is runnit supported by AirVpn Suite installer? I have nothing against testing AirVPN Suite :).

Hello!

Sorry, the installer can't configure Bluetit to start automatically at bootstrap within runit specifications reported here https://docs.voidlinux.org/config/services/index.html , so you will need to configure it manually (or just run it at boot in some init script - Bluetit will be able to connect and activate Network Lock even in this way, if specified in the run control file bluetit.rc).

Kind regards