Arch Linux User Repository

Would it be possible to put an exec in /usr/bin/pacserve to get rid of the intermediate bash process after start-up? There doesn't seem to be a benefit to keeping the eternally sleeping process around and Bash is notoriously bothersome about signal handling.

@jlp2 it's actually an issue with the threaded-servers dependency. There's a deprecated method ".tostring()" used.

While you wait for upstream, you can fix it by replacing the .tostring() with .tobytes() in /usr/lib/python3.9/site-packages/ThreadedServers/common.py

Today the python 3.9.0 update arrived in the repos. I rebuilt pacserve and python3-threaded_servers, but pacserve no longer starts.

gero@COMPUTER-b ~ $ systemctl status pacserve
● pacserve.service - Pacserve
     Loaded: loaded (/usr/lib/systemd/system/pacserve.service; enabled; vendor preset: disabled)
    Drop-In: /etc/systemd/system/pacserve.service.d
             └─override.conf
     Active: activating (auto-restart) (Result: exit-code) since Wed 2020-12-02 11:40:14 CET; 3s ago
    Process: 908 ExecStart=/usr/bin/pacserve $PACSERVE_ARGS (code=exited, status=1/FAILURE)
   Main PID: 908 (code=exited, status=1/FAILURE)

@Xyne the first look is on the AUR page if a program doesn't work as expected and so i think this page is a suitable place for a hint also possible is a post installation message

@Xyne I think an explanation can be found in https://bugs.mageia.org/show_bug.cgi?id=15425

@brikler The wiki has always said to enable avahi-daemon.service, so I don't think any hint is necessary. https://wiki.archlinux.org/index.php/Avahi#Installation

@brikler I'm open to the idea but what kind of hint do you mean? Where would be it shown?

Unless Pacserve is doing something wrong, I consider this an issue with Avahi's socket activation. I did a quick search for similar issues to see what I could find and this popped up: https://bugs.archlinux.org/task/60012

Unfortunately, the cited explanation is no longer available at the given URL.

@xyne this was my first thought, but i think now a hint would be better

@brikler Given that Avahi is optional, I'm reluctant to require it in the service file. Is there a reason to not just enable both at the same time?

could you add Requires=avahi-daemon.serviceto the systemd service file? on my system avahi-daemon.socketdoesn't trigger avahi-daemon.service when pacserve need the avahi-daemon

without running avahi-daemon this error occurs

 pacserve.service - Pacserve
     Loaded: loaded (/usr/lib/systemd/system/pacserve.service; disabled; vendor preset: disabled)
     Active: active (running) since Sun 2020-07-19 15:57:26 CEST; 43min ago
   Main PID: 458 (pacserve)
      Tasks: 6 (limit: 4534)
     Memory: 28.8M
     CGroup: /system.slice/pacserve.service
             |-458 /bin/bash /usr/bin/pacserve --multicast --avahi
             `-459 python3 -mThreadedServers.Pacserve --multicast --avahi

Jul 19 15:57:26 frija systemd[1]: Started Pacserve.
Jul 19 15:57:26 frija pacserve[459]: [2020-07-19 15:57:26 CEST] INFO: registering via avahi
Jul 19 15:57:26 frija pacserve[459]: [2020-07-19 15:57:26 CEST] ERROR: exception encountered in Avahi listener thread: org.freedesktop.systemd1.NoSuchUnit: Unit db>
Jul 19 15:57:26 frija pacserve[459]: [2020-07-19 15:57:26 CEST] ERROR: exception encountered in Avahi announcer thread: org.freedesktop.systemd1.NoSuchUnit: Unit d>
Jul 19 15:57:27 frija pacserve[459]: [2020-07-19 15:57:27 CEST] INFO: sending multicast message to (224.3.45.67, 15679) via 127.0.0.1
Jul 19 15:57:27 frija pacserve[459]: [2020-07-19 15:57:27 CEST] INFO: sending multicast message to (224.3.45.67, 15679) via 192.168.2.100

@C0rn3j Fixed. Sorry for the delay. I'll push the update this evening.