You are not logged in.
It shouldn't break it. The worst it will do is return 404 Not Found errors as it does for missing packages.
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
Howdy - and thanks for this amazing tool!
Been using it for a while now, works flawlessly everytime!
I just have a quick question:
I've just started to use the [testing] repo on one of the machine (say machine B).
From what I understand, pacserve is not aware of repositories, so if I upgrade machine B before machine A, machine B will feed packages from [testing] (since they have the same name than those in [extra/core] ) to machine A, is that right?
Hasta la Singularidad Siempre
Offline
Hi Xnye,
thanks for the nifty tool. I seem to have a problem with sharing packages, which contain a colon in their name.
For example I tried sharing lirc-1:0.9.0-16-x86_64.pkg.tar.xz but the client received lirc-utils-1%3A0.9.0-16-x86_64.pkg.tar.xz and pacman complained about integrity. So I had to rename that package on the client and the upgrade worked as expected.
Offline
It should work now. Try the latest version and let me know.
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
It should work now. Try the latest version and let me know.
Tried it again with pacserve-2012.5-2 on both server and client, but the problem remained. Here are the logs, maybe they are helpful.
pacserve Sever:
pacserve --multicast
Starting Pacserve...
address: all interfaces
port: 15678
pid: 4147
Press <Ctrl-C> to exit.
[2012-05-12 11:55:28] multicast group and port: (224.3.45.67, 15679)
[2012-05-12 11:55:28] announcing presence via multicast
[2012-05-12 11:55:28] listening for multicasts on port 15679, all interfaces
[2012-05-12 11:55:29] adding: 192.168.178.20:15678 to server pool
[2012-05-12 11:55:39] 192.168.178.20:54051 "GET /search/extra/x86_64/lirc-1%3A0.9.0-16-x86_64.pkg.tar.xz?queried=127.0.0.1%3A15678&queried=192.168.178.20%3A15678&queried=htpc%3A15678&queried=localhost.localdomain%3A15678&queried=192.168.178.21%3A15678&queried=localhost%3A15678 HTTP/1.0" 200 -
[2012-05-12 11:55:39] 192.168.178.20:54052 transferring /var/cache/pacman/pkg/lirc-1:0.9.0-16-x86_64.pkg.tar.xz
[2012-05-12 11:55:39] 192.168.178.20:54052 "GET /request/extra/x86_64/lirc-1%3A0.9.0-16-x86_64.pkg.tar.xz HTTP/1.1" 200 -
^C<Ctrl-C> pressed, exiting...
pacserve Client:
pacserve --multicast
Starting Pacserve...
address: all interfaces
port: 15678
pid: 925
Press <Ctrl-C> to exit.
[2012-05-12 11:55:31] multicast group and port: (224.3.45.67, 15679)
[2012-05-12 11:55:31] announcing presence via multicast
[2012-05-12 11:55:31] listening for multicasts on port 15679, all interfaces
[2012-05-12 11:55:31] adding: 192.168.178.21:15678 to server pool
[2012-05-12 11:55:35] 127.0.0.1:39967 querying ftp://ftp.tu-chemnitz.de/pub/linux/archlinux/core/os/x86_64/core.db
[2012-05-12 11:55:36] 127.0.0.1:39967 redirecting to ftp://ftp.tu-chemnitz.de/pub/linux/archlinux/core/os/x86_64/core.db
[2012-05-12 11:55:36] 127.0.0.1:39967 "GET /request/core/x86_64/core.db HTTP/1.1" 303 -
[2012-05-12 11:55:37] 127.0.0.1:39967 querying ftp://ftp.tu-chemnitz.de/pub/linux/archlinux/extra/os/x86_64/extra.db
[2012-05-12 11:55:37] 127.0.0.1:39967 redirecting to ftp://ftp.tu-chemnitz.de/pub/linux/archlinux/extra/os/x86_64/extra.db
[2012-05-12 11:55:37] 127.0.0.1:39967 "GET /request/extra/x86_64/extra.db HTTP/1.1" 303 -
[2012-05-12 11:55:38] 127.0.0.1:39967 querying ftp://ftp.tu-chemnitz.de/pub/linux/archlinux/community/os/x86_64/community.db
[2012-05-12 11:55:38] 127.0.0.1:39967 redirecting to ftp://ftp.tu-chemnitz.de/pub/linux/archlinux/community/os/x86_64/community.db
[2012-05-12 11:55:38] 127.0.0.1:39967 "GET /request/community/x86_64/community.db HTTP/1.1" 303 -
[2012-05-12 11:55:41] querying http://192.168.178.21:15678/search/extra/x86_64/lirc-1%3A0.9.0-16-x86_64.pkg.tar.xz?queried=127.0.0.1%3A15678&queried=192.168.178.20%3A15678&queried=htpc%3A15678&queried=localhost.localdomain%3A15678&queried=192.168.178.21%3A15678&queried=localhost%3A15678
[2012-05-12 11:55:41] 127.0.0.1:39967 redirecting to http://192.168.178.21:15678/request/extra/x86_64/lirc-1%3A0.9.0-16-x86_64.pkg.tar.xz
[2012-05-12 11:55:41] 127.0.0.1:39967 "GET /request/extra/x86_64/lirc-1:0.9.0-16-x86_64.pkg.tar.xz HTTP/1.1" 303 -
^C<Ctrl-C> pressed, exiting...
pacman Client:
LANG=en_US; sudo pacman -Syu
:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
:: Starting full system upgrade...
resolving dependencies...
looking for inter-conflicts...
Targets (1): lirc-1:0.9.0-16
Total Download Size: 0.02 MiB
Total Installed Size: 0.04 MiB
Net Upgrade Size: 0.02 MiB
Proceed with installation? [Y/n]
:: Retrieving packages from extra...
lirc-1:0.9.0-16-x86_64 22.4 KiB 2.12M/s 00:00 [########################################################] 100%
(1/1) checking package integrity [########################################################] 100%
error: failed to commit transaction (wrong or NULL argument passed)
Errors occurred, no packages were upgraded.
It's still /var/cache/pacman/pkg/lirc-1%3A0.9.0-16-x86_64.pkg.tar.xz
Offline
I just double-checked this here with lirc. The package is transferred and saved with the correct name. There are no errors in the package.
There may be an error in the lirc package on the server. The pacman output that you posted may indicate another error. It seems to pass the integrity check then fail on something else.
Remove the misnamed file on both the server and the client, then check the integrity of the package on the server.
You can also run "pacman -Sw lirc --cachedir /some/empy/directory" on the client and then compare the downloaded package to the one on the server.
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
Thanks Xyne, the error was due to the erroneous lirc package on the server. It works now.
Last edited by olebowle (2012-05-13 16:24:17)
Offline
I'm having trouble getting pacserve to start with systemd. I get this after startup:
$ systemctl status pacserve.service
pacserve.service - Pacserve
Loaded: loaded (/usr/lib/systemd/system/pacserve.service; enabled)
Active: inactive (dead) (Result: exit-code) since Mon, 27 Aug 2012 12:27:16 +0100; 1h 23min ago
Process: 829 ExecStart=/usr/bin/pacserve --multicast (code=exited, status=1/FAILURE)
CGroup: name=systemd:/system/pacserve.service
I can manually restart it using systemctl restart pacserve and pacserve will work
Any ideas?
Thanks for creating this piece of software, it's truly excellent and saves so much bandwidth!
Last edited by will.price94 (2012-08-27 12:53:49)
Offline
Sorry, I still haven't switched to systemd. The service file was contributed by someone else and I know very little about it. I will update the package if someone posts a solution, otherwise I'll take a look at it after I switch over to systemd (hopefully in a week or two). After that, I will dig into the systemd documentation and provide all necessary service files for my packages.
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
At boot, pacserve fails to start correctly on both my computers.
Here is the output of systemctl status pacserve after boot:
pacserve.service - Pacserve
Loaded: loaded (/usr/lib/systemd/system/pacserve.service; enabled)
Active: active (running) since Πεμ 2013-04-04 08:54:05 EEST; 1min 27s ago
Main PID: 448 (python2)
CGroup: name=systemd:/system/pacserve.service
└─448 python2 /usr/bin/pacserve --pid-file /run/pacserved.pid --multicast
Απρ 04 08:54:07 dynamo pacserve[448]: Traceback (most recent call last):
Απρ 04 08:54:07 dynamo pacserve[448]: File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner
Απρ 04 08:54:07 dynamo pacserve[448]: self.run()
Απρ 04 08:54:07 dynamo pacserve[448]: File "/usr/lib/python2.7/threading.py", line 504, in run
Απρ 04 08:54:07 dynamo pacserve[448]: self.__target(*self.__args, **self.__kwargs)
Απρ 04 08:54:07 dynamo pacserve[448]: File "/usr/bin/pacserve", line 704, in run_multicast_server
Απρ 04 08:54:07 dynamo pacserve[448]: sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq)
Απρ 04 08:54:07 dynamo pacserve[448]: File "/usr/lib/python2.7/socket.py", line 224, in meth
Απρ 04 08:54:07 dynamo pacserve[448]: return getattr(self._sock,name)(*args)
Απρ 04 08:54:07 dynamo pacserve[448]: error: [Errno 19] No such device
As a result, the computers cannot communicate.
After I do a systemctl restart pacserve, everything is fine:
pacserve.service - Pacserve
Loaded: loaded (/usr/lib/systemd/system/pacserve.service; enabled)
Active: active (running) since Πεμ 2013-04-04 08:55:40 EEST; 2s ago
Main PID: 1395 (python2)
CGroup: name=systemd:/system/pacserve.service
└─1395 python2 /usr/bin/pacserve --pid-file /run/pacserved.pid --multicast
Απρ 04 08:55:40 dynamo systemd[1]: Starting Pacserve...
Απρ 04 08:55:40 dynamo systemd[1]: Started Pacserve.
Απρ 04 08:55:41 dynamo pacserve[1395]: [2013-04-04 08:55:41] multicast group and port: (224.3.45.67, 15679)
Απρ 04 08:55:41 dynamo pacserve[1395]: [2013-04-04 08:55:41] listening for multicasts on port 15679, all interfaces
Απρ 04 08:55:41 dynamo pacserve[1395]: [2013-04-04 08:55:41] announcing presence via multicast
I should probably note that I am using pacserve by having added the lines
Include = /etc/pacman.d/pacserve
in pacman.conf and then calling pacman or yaourt.
Offline
Try the new version and let me know if it resolves the issue. You will likely see a few error messages due to the socket not being ready when it starts, but it should now exit and be restarted automatically.
If anyone has any suggestions of how to enforce correct ordering in the service file, please tell me.
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
Unfortunately it does not work. It seems it does not erase /run/pacserved.pid while stopping, so it cannot restart.
After boot, I get
pacserve.service - Pacserve
Loaded: loaded (/usr/lib/systemd/system/pacserve.service; enabled)
Active: inactive (dead) (Result: exit-code) since Σαβ 2013-04-06 00:05:34 EEST; 1min 32s ago
Process: 538 ExecStart=/usr/bin/pacserve --pid-file $PID_FILE $PACSERVE_ARGS (code=exited, status=1/FAILURE)
Απρ 06 00:05:37 dynamo pacserve[452]: address: all interfaces
Απρ 06 00:05:37 dynamo pacserve[452]: port: 15678
Απρ 06 00:05:37 dynamo pacserve[452]: pid: 452
Απρ 06 00:05:37 dynamo pacserve[452]: Press <Ctrl-C> to exit.
Απρ 06 00:05:37 dynamo pacserve[476]: Traceback (most recent call last):
Απρ 06 00:05:37 dynamo pacserve[476]: File "/usr/bin/pacserve", line 1082, in <module>
Απρ 06 00:05:37 dynamo pacserve[476]: main()
Απρ 06 00:05:37 dynamo pacserve[499]: error: found existing PID file (/run/pacserved.pid), refusing to start
Απρ 06 00:05:37 dynamo pacserve[519]: error: found existing PID file (/run/pacserved.pid), refusing to start
Απρ 06 00:05:37 dynamo pacserve[538]: error: found existing PID file (/run/pacserved.pid), refusing to start
and after a restart I get
pacserve.service - Pacserve
Loaded: loaded (/usr/lib/systemd/system/pacserve.service; enabled)
Active: inactive (dead) (Result: exit-code) since Σαβ 2013-04-06 00:11:15 EEST; 1s ago
Process: 2021 ExecStart=/usr/bin/pacserve --pid-file $PID_FILE $PACSERVE_ARGS (code=exited, status=1/FAILURE)
Απρ 06 00:11:15 dynamo systemd[1]: Unit pacserve.service entered failed state
Απρ 06 00:11:15 dynamo systemd[1]: pacserve.service holdoff time over, scheduling restart.
Απρ 06 00:11:15 dynamo systemd[1]: Stopping Pacserve...
Απρ 06 00:11:15 dynamo systemd[1]: Dependency failed for Pacserve.
Thanks for all the effort and this wonderful program!
Offline
Try pacserve-2013.4.6-1. You may need to remove the existing PID file if you want to start it without rebooting, but after that it should always be removed automatically.
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
Hello,
pacserve is truly awesome ! Thank you for this gem !
I also stumbled with the issue of the existing pid file at startup. I see the last version (4.6) deletes the pid file when it is closed. The issue is if there is a hard reboot, the pid file isn't removed, so upon startup, it will fail to start, seeing that there is a pid file.
Here's a little patch that reads the pid file and verifies if the process exists :
--- pacserve 2013-04-06 04:11:24.000000000 +0200
+++ /usr/bin/pacserve 2013-04-06 15:39:51.352239845 +0200
@@ -907,8 +907,14 @@
if pid != 0:
if options.pid_file:
if os.path.exists(options.pid_file):
- sys.stderr.write('error: found existing PID file (%s), refusing to start' % options.pid_file)
- sys.exit(1)
+
+ # Verify that the process given in the file acually links to an existing
+ # process.
+ with open(options.pid_file, 'r') as f:
+ old_pid = f.read()
+ if old_pid != "" and os.path.exists('/proc/%s' % old_pid):
+ sys.stderr.write('error: found existing PID file (%s), refusing to start' % options.pid_file)
+ sys.exit(1)
try:
with open(options.pid_file, 'w') as f:
f.write("%d" % pid)
Is it valid enough for you (Xyne) to integrate it in your code ? I haven't seen any other way to submit code to you, and think it can be valuable to anyone.
Offline
Note that this patch isn't solid enough : if the file already exists and there is a pid of a previous pacserve, it will think there is no pacserve running and overwrite the existing value with the new pacserve. But if the old pid has more digits, then writing the new pid will not be enough (because there will be some digits of the old one!)
Here's a more robust version :
--- pacserve 2013-04-06 04:11:24.000000000 +0200
+++ /usr/bin/pacserve 2013-04-06 16:12:52.088940752 +0200
@@ -907,8 +907,21 @@
if pid != 0:
if options.pid_file:
if os.path.exists(options.pid_file):
- sys.stderr.write('error: found existing PID file (%s), refusing to start' % options.pid_file)
- sys.exit(1)
+
+ remove_pid_file = False
+ # Verify that the process given in the file acually links to an existing
+ # process.
+ with open(options.pid_file, 'r') as f:
+ old_pid = f.read()
+ if old_pid != "" and os.path.exists('/proc/%s' % old_pid):
+ sys.stderr.write('error: found existing PID file (%s), refusing to start' % options.pid_file)
+ sys.exit(1)
+ else:
+ remove_pid_file = true
+
+ if remove_pid_file:
+ remove_pid_file()
+
try:
with open(options.pid_file, 'w') as f:
f.write("%d" % pid)
Offline
If there is a hard reboot, there will be no PID file because /run is in tmpfs.
Nevertheless, checking if the previous process is still active is indeed more robust. I have applied your patch with some changes (pacserve-2013.4.6.1). Thanks for the patches and welcome to the forum!
Note to self: I really need to clean up the mess of noobish Python code that I've been meaning to convert to Python 3 for at least a year.
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
Unfortunately, pacserve still fails to start at boot most of the times. Here is a typical status:
pacserve.service - Pacserve
Loaded: loaded (/usr/lib/systemd/system/pacserve.service; enabled)
Active: inactive (dead) (Result: exit-code) since Σαβ 2013-04-13 08:40:12 EEST; 24min ago
Process: 464 ExecStart=/usr/bin/pacserve --pid-file $PID_FILE $PACSERVE_ARGS (code=exited, status=2)
Απρ 13 08:40:12 dynamo systemd[1]: Unit pacserve.service entered failed state
Απρ 13 08:40:12 dynamo systemd[1]: pacserve.service holdoff time over, scheduling restart.
Απρ 13 08:40:12 dynamo systemd[1]: Stopping Pacserve...
Απρ 13 08:40:12 dynamo systemd[1]: Dependency failed for Pacserve.
... and on my laptop it says something different:
pacserve.service - Pacserve
Loaded: loaded (/usr/lib/systemd/system/pacserve.service; enabled)
Active: failed (Result: start-limit) since Σαβ 2013-04-13 09:08:27 EEST; 2min 14s ago
Process: 751 ExecStart=/usr/bin/pacserve --pid-file $PID_FILE $PACSERVE_ARGS (code=exited, status=1/FAILURE)
Απρ 13 09:08:27 woody systemd[1]: Unit pacserve.service entered failed state
Απρ 13 09:08:27 woody systemd[1]: pacserve.service holdoff time over, scheduling restart.
Απρ 13 09:08:27 woody systemd[1]: Stopping Pacserve...
Απρ 13 09:08:27 woody systemd[1]: Starting Pacserve...
Απρ 13 09:08:27 woody systemd[1]: pacserve.service start request repeated too quickly, refusing to start.
Απρ 13 09:08:27 woody systemd[1]: Failed to start Pacserve.
Απρ 13 09:08:27 woody systemd[1]: Unit pacserve.service entered failed state
Of course, if I restart, everything is fine.
Last edited by nplatis (2013-04-13 06:12:08)
Offline
I tried to remove pacserve (pacman -Rns pacserve) to install it cleanly and I notice that after removal, the following files remain on my system:
/etc/systemd/system/pacserve.service.requires
/etc/systemd/system/multi-user.target.wants/pacserve.service
/etc/systemd/system/pacserve.service.requires/pacserve-ports.service
I don't know if this is expected.
Last edited by nplatis (2013-04-13 07:47:28)
Offline
Regarding my previous error messages, an error message I currently get is
pacserve: error: --pid-file option requires an argument
which indicates (at least to me) that the EnvironmentFile is not processed correctly. I think this happens after the latest update to systemd 201.
Offline
Doubling the variable definitions in /etc/conf.d/pacserve, i.e.:
PID_FILE="/run/pacserved.pid"
PID_FILE="/run/pacserved.pid"
...
PACSERVE_ARGS="--multicast"
PACSERVE_ARGS="--multicast"
might be a particularly terrible quickfix, but it seems to work.
Offline
When you enable a service, systemd creates symlinks in /etc/systemd/system. Those are not owned by any package and it is normal that they remain after removing the package with the files that they link.
The Pacserve service depends on the systemd network.target. If you configure your network manually then you should also configure pacserve manually. Without knowing more about the system I cannot help.
I have added a restart delay to the pacserve.service file which should hopefully take care of the second error. I have also split the configuration file in case there was some issue with the pacserve-ports Bash array at the end of that file.
Please update and let me know if the problem is solved.
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
When you enable a service, systemd creates symlinks in /etc/systemd/system. Those are not owned by any package and it is normal that they remain after removing the package with the files that they link.
The Pacserve service depends on the systemd network.target. If you configure your network manually then you should also configure pacserve manually. Without knowing more about the system I cannot help.
OK about these two.
About the first, I thought that removing a package should disable the service, if enabled, but it seems this is not the case.
I have added a restart delay to the pacserve.service file which should hopefully take care of the second error. I have also split the configuration file in case there was some issue with the pacserve-ports Bash array at the end of that file.
Please update and let me know if the problem is solved.
The problem persists, and the "solution" proposed above by spacebison seems to magically work (I checked with the latest version that you just uploaded).
Offline
I am unable to fix the issue by duplicating the variables in the config files. Basically looping over this:
root@deadwing /etc/pacserve # systemctl status pacserve.service
pacserve.service - Pacserve
Loaded: loaded (/usr/lib/systemd/system/pacserve.service; enabled)
Active: failed (Result: start-limit) since Sat 2013-04-13 22:34:19 BRT; 721ms ago
Process: 10782 ExecStart=/usr/bin/pacserve --pid-file $PID_FILE $PACSERVE_ARGS (code=exited, status=1/FAILURE)
Apr 13 22:34:18 deadwing systemd[1]: Unit pacserve.service entered failed state
Apr 13 22:34:19 deadwing systemd[1]: pacserve.service holdoff time over, scheduling restart.
Apr 13 22:34:19 deadwing systemd[1]: Stopping Pacserve...
Apr 13 22:34:19 deadwing systemd[1]: Starting Pacserve...
Apr 13 22:34:19 deadwing systemd[1]: pacserve.service start request repeated too quickly, refusing to start.
Apr 13 22:34:19 deadwing systemd[1]: Failed to start Pacserve.
Apr 13 22:34:19 deadwing systemd[1]: Unit pacserve.service entered failed state
Offline
I think that spychalski is experiencing the timeout problem, which I am experiencing too if I enable pacserve to start on boot.
Regarding the configuration problem. the way I seem to get over it is to remove all comments from /etc/pacserve/pacserve.service.conf
It seems that these EnvironmentFile's are not bash scripts, but I have not been able to find their specification anywhere.
Offline
Worth noting that starting pacserve manually (currently doing it via tmux) works perfect. Doing this on 3 machines since none of them are able to start the service.
Offline