search

YACReader / yacreader

This repo contains the code of YACReader's desktop version.
https://www.yacreader.com
GNU General Public License v3.0
956 stars 94 forks source link

Connection error when i try to open comic book #362

Open peter099 opened 1 year ago

peter099 commented 1 year ago

I am using YACreader on MX Linux, the version is 9.10.0.0. Application was working fine, but today when i tried to open a comic book in YACreader library i get popup window with error that say Unable to connect to YACreaderLibrary. If i start YACreader Library from terminal i get this:

$ YACReaderLibrary
ERROR 2022-12-15T17:41:08.500 Unable to create local server

Any idea what is the problem? My comic book files are on the hard disk on my laptop.

dreamofi commented 1 year ago

I also had this issue on MX Linux 21, and solved it by opening YACReaderLibrary with sudo in the terminal once, creating a new library and pointing to the comics folder. After running with sudo, opening YACReaderLibrary normally works again:

sudo YACReaderLibrary

peter099 commented 1 year ago

Thanks, that worked. Though i still think this is a bug that need to be addressed by developer.

fondfire commented 1 year ago

I am having this problem EVERY time I open YACReaderLibrary. After a lot of searching, dreamofi's solution was the only thing working for me... but I thought "Why in the HECK do I need this after every reboot of my workstation?" So, I have my /tmp filesystem mounted to a RAMdisk filesystem; it's wiped at every boot.

I finally noticed this file in /tmp is owned by lightdm after boot:

srwxrwxr-x 1 lightdm lightdm 0 Apr 1 02:52 ea343ff3-2005-4865-b212-7fa7c43999b8

So, I noticed after running sudo YACReaderLibrary, closing that out, and then reopening YACReaderLibrary myself, the file ownership changed to be owned by meself:

srwxrwxr-x 1 fondfire fondfire 0 Apr 1 02:52 ea343ff3-2005-4865-b212-7fa7c43999b8

So, I tried rebooting and just running sudo chown fondfire:fondfire /tmp/ea343ff3-2005-4865-b212-7fa7c43999b8. BOOM! Problem solved and no need to run sudo YACReaderLibrary to fix it.

I'm not sure what the heck that socket file does, but yes, the developers need to work around that!

selmf commented 1 year ago

Allow me to elaborate.

ea343ff3-2005-4865-b212-7fa7c43999b8 is the GUID, the Globally Unique Identifier we use to identify YACReaderLibrary and also YACReaderLibraryServer running on a system. If that ID is already taken, the library will not start. If it is taken by a process different from YACReaderLibrary, YACReader synchronization will not work.

I have no idea what causes a situation like this. If I run YACReaderLibrary 9.11.0 on my system, the socket with the GUID appears on /tmp and it disappears after I close YACReaderLibrary. The chances of lightdm creating it with our GUID are next to nothing and it should not persist, let alone persist over reboots.

An educated guess would be that there is a situation which causes lightdm to take ownership of the socket and recreating it at boot time. I have no idea if such a mechanism exists though.

Addendum: Of course, if lightdm takes ownership over the socket, YACReader*Library can only use it if it has the proper access rights, which is why it works when running as root.

fondfire commented 1 year ago

That all makes plenty of sense! Why running sudo YACReaderLibrary changes the ownership to the 'fondfire' user instead of the 'root' user isn't entirely clear to me, but probably has to do with the 'fondfire' user being the one running sudo. But sometimes the Son of Fondfire (with username 'soff') also wants to read comics. And he doesn't have the rights to use sudo. Does this mean I need to login and run sudo chmod soff:soff /tmp/ea343ff3-2005-4865-b212-7fa7c43999b8 so he can use it, if he logs in after me? With enough users on a computer, this quickly compounds...

I suspect 'lightdm' gets ownership in part because of this relatively recent addition to the package for Ubuntu: /usr/lib/systemd/user/yacreaderlibraryserver.service. It's useful to have this as a service, no doubt! But it starts up every time I login and I can't seem to deactivate that behavior. I actually thought at one point that it IS the problem. It really doesn't SEEM to be. Once I change the ownership of the socket, it's fine. But I'm assuming something about this gets run by 'lightdm' as I login, since I login from the lightdm Display Manager.

What I see a lot of other programs do is tag the username on the socket name. That way, the 'fondfire' user gets /tmp/fondfire_ea343ff3-2005-4865-b212-7fa7c43999b8 and the conflict never occurs.

dreamofi commented 1 year ago

from @fondfire finding, I've added a little script into /etc/rc.local to change the owner and group of the file /tmp/ea343ff3-2005-4865-b212-7fa7c43999b8 upon every boot. Since then everything seems to work normally:

if [ -e "/tmp/ea343ff3-2005-4865-b212-7fa7c43999b8" ];
then
chgrp <group_name> "/tmp/ea343ff3-2005-4865-b212-7fa7c43999b8"
chown <owner_name> "/tmp/ea343ff3-2005-4865-b212-7fa7c43999b8"
fi

please insert your group name and owner name into and , respectively

selmf commented 1 year ago

The sudo workaround does not change the ownerhship. What should happen is this:

1) You start YACReaderLibrary with sudo, which enables it to write to the socket 2) You close it and on closing the socket is properly removed 3) You start it as a normal user and it creates the socket with your rights

Now, to get to the bottom of this problem I need some help from you all. Please confirm some things for me.

1) Is the socket after reboot owned by lightdm? 2) After step two of the sequence I described above, is the socket gone? 3) Check the output of systemctl --user status yacreaderlibraryserver and also systemctl status yacreaderlibraryserver to check if the headless library service is enabled (by default it should be not) 4) Please give me some information about the Linux Distros, configurations and versions of YACReader you all are running:

adriou commented 1 year ago

Same problem on Xubuntu 22.04 installed with .deb package for Ubuntu 22.04

Note that after removing /usr/lib/systemd/user/yacreaderlibraryserver.service the problem is gone (after reboot of course).

fondfire commented 1 year ago

First off... Yes, I'm using the official repository at http://download.opensuse.org/repositories/home:/selmf/xUbuntu_22.04/ and currently have version 9.11.0-1 installed. Every time a new version is posted to that repository, I install it with the rest of the updates to my system. I'm trying to be a "dumb end user" here most of the time... and while I'm not sure WHY this hasn't been added to the Ubuntu "universe" repository, it hasn't. So, this remains "the Way" to get it...

So, after getting a little time to poke around, I found the following:

Whatever the case, this seems to be the cause...

fondfire commented 1 year ago

Side issue... It's really quite common for my son and I to be logged in at the same time. I log in, walk away, and go start doing something outside. He sits down, hits "Switch user" button on my lock screen, and logs into a second user session.

Now, if I left a YACReaderLibrary session running when I walked away and my screen locked, what happens when my son also tries to launch YACReaderLibrary? He's not as into American comics as I am (and his manga is still all on paper... for now), but if he gets curious about a Marvel movie and wants to start digging through Dad's collection (which is in a shared directory that we can all access)... will he be able to launch a session?

I realize this "two users both with YACReaderLibrary running" scenario is somewhat uncommon on a workstation or laptop, but... Yeah, it happens. Admittedly, my son and I are using the same library (and mine is read-only to him), but... particularly if he had an entirely separate library, shouldn't he still be able to use it while I'm running mine? This is part of why I'm wondering if each user shouldn't have their own socket, which would have also prevented the lightdm thing from being a problem.

selmf commented 1 year ago

Thank you all for investigating this issue. After some research, this is the conclusion:

YACReader by default installs a user systemd service file for the headless library server. This is a convenience for users and is intended to be disabled by default and enabled by the user if they wish so (opt-in).

Debian packaging however switched to automatically enabling and starting systemd service files shipped by packages. To avoid this, the packager needs to explicitly disable this behavior (opt-out).

Since service files are automatically enabled and started, seemingly for every user including lightdm, yacreaderlibraryserver.service now runs where it shouldn't and is breaking havoc.

There are also some other bugs and issues that contribute to the specific socket issue (not cleaning up the socket on ungraceful exit, sub-optimal mechanism for instance management), but this is the root of the problem.

For MX-Linux users this means you have to contact the packager and ask for a fix. For users of the semi-official packages you have to wait for me to figure out the proper opt-out process and update the .deb packages.

As a workaround, you can try disabling or masking the service.

fondfire commented 1 year ago

On autostarting YACReaderLibraryServer...

While systemd is mad capable, the freedesktop.org standards specify an autostart standard that I think might be more appropriate and easy to manage than a systemd user service. An /etc/xdg/autostart/YACReaderLibraryServer.desktop file would have about the same effect (but likely more graceful) than /usr/lib/systemd/user/yacreaderlibraryserver.service, but it could readily be copied to ~/.config/autostart/ and manipulated more readily. It's the more expected way to "opt-in" to a "service" for a desktop user. But it's also not that hard to adapt it to autostart on a headless RPi or whatnot just to provide the library to the end user. This XDG mechanism is simple, more in line with old school "Unix philosophy", and can more readily be manipulated by the graphical tools provided by each of the most popular desktop suites for Linux. While systemd has solved a lot of problems, it's difficult for everyone to casually wrap their heads around it.

I think systemd WOULD make more sense for a service to start-up at boottime. But that doesn't seem to be how the user services really work anyway; they don't seem to get activated until the user "logs in". In any case, even if you DID want to start-up YACReaderLibraryServer at boottime (and I'm sure that is a pretty common use case), that needs to be configured on the first go by the end user to specify WHICH user should own the service and WHICH library(ies) should be advertised. If YACReaderLibraryServer is running, I'm not having any luck in ALSO starting YACReaderLibrary, so... it seems to be one or the other anyway. And further, at least for now, it doesn't seem multiple YACReaderLibraryServer instances for various users on the same system could possibly run at the same time for now (though that could be quite useful, really).

I certainly do NOT fully understand YACReader, systemd, or exactly what's trying to be made available here. But this alternative mechanism is one I'm familiar with because far more end-user graphical programs utilize it.

Thanks!

selmf commented 1 year ago

I've updated the .deb packages for v 9.12.0 of YACReader.

Changes:

Updating to the newest version should remove the headless server and fix things for you. Please confirm if that is the case.

Unfortunately, I cannot do anything about the MX Linux package as it is a downstream release. They can however copy my fixes from https://github.com/selmf/yacreader-deb if they wish to.

fondfire commented 1 year ago

Hey, thanks! It's working well for me.