As reported in ML: [root@jaglap system]# systemctl start rsyncd.socket [root@jaglap system]# systemctl status rsyncd.socket rsyncd.socket - Rsync Server Socket Loaded: loaded (/usr/lib/systemd/system/rsyncd.socket; disabled) Active: active (listening) since Mon 2014-03-03 13:06:09 EST; 4s ago Listen: [::]:873 (Stream) Accepted: 0; Connected: 0 Mar 03 13:06:09 jaglap systemd[1]: Listening on Rsync Server Socket. [root@jaglap system]# rsync localhost:: rsync: safe_read failed to read 1 bytes [Receiver]: Connection reset by peer (104) rsync error: error in rsync protocol data stream (code 12) at io.c(251) [Receiver=3.1.0] [root@jaglap system]# systemctl status -a rsyncd.socket rsyncd.socket - Rsync Server Socket Loaded: loaded (/usr/lib/systemd/system/rsyncd.socket; disabled) Active: failed (Result: resources) since Mon 2014-03-03 13:06:31 EST; 4min 30s ago Listen: [::]:873 (Stream) Accepted: 1; Connected: 0 Mar 03 13:06:09 jaglap systemd[1]: Listening on Rsync Server Socket. Mar 03 13:06:31 jaglap systemd[1]: rsyncd.socket failed to queue service startup job (Maybe the service file is missing or not a template unit?): Invalid argument Mar 03 13:06:31 jaglap systemd[1]: Unit rsyncd.socket entered failed state. [root@jaglap system]# cat rsyncd.socket [Unit] Description=Rsync Server Socket Conflicts=rsyncd.service [Socket] ListenStream=873 Accept=yes [Install] WantedBy=sockets.target However, googling I found https://together.jolla.com/question/19492/rsync-daemon-mode-as-a-systemd-socket-listener/ , which indicates that an additional service file is needed: Create /etc/systemd/system/rsyncd@.service: [Unit] Description=Rsync Server After=local-fs.target ConditionPathExists=/etc/rsyncd.conf [Service] # Note: this requires /etc/rsyncd.conf ExecStart=/usr/bin/rsync --daemon StandardInput=socket We don't seem to have this. Reproducible: Steps to Reproduce:
CC: (none) => makowski.mageiaSource RPM: systemd => rsync
from Fedora rsyncd@.service: [Unit] Description=fast remote file copy program daemon ConditionPathExists=/etc/rsyncd.conf [Service] EnvironmentFile=/etc/sysconfig/rsyncd ExecStart=/usr/bin/rsync --daemon --no-detach "$OPTIONS" StandardInput=socket
Version: Cauldron => 4
Fixed in rsync-3.1.0-6.mga5 and rsync-3.1.0-4.1.mga4. Advisory: ---------------------------------------- The rsyncd service for running an rsync server, as shipped in the Mageia 4 rsync package, is controlled by a systemd socket-activated unit, rsync.socket. It was not working correctly due to the package not containing another needed component. This has been corrected. ---------------------------------------- Updated packages in core/updates_testing: ---------------------------------------- rsync-3.1.0-4.1.mga4 from rsync-3.1.0-4.1.mga4.src.rpm
CC: (none) => luigiwalserHardware: x86_64 => AllAssignee: bugsquad => qa-bugs
The initial mailing list report cited by Frank: https://ml.mageia.org/l/arc/discuss/2014-03/msg00003.html
Checked rsync-3.1.0-4.1.mga4 on x86_64. The missing file now does exists, rsyncd is correctly started if the rsyncd.socket had already been started when the package is installed / upgraded. But when rsync-3.1.0-4.1 is installed from scratch (no rsyncd socket active at the time of the install), it does not automatically start rsyncd, and access to rsync from another machine then fails. The spec file probably lacks a post install clause that enables/starts the socket.
CC: (none) => juergen.harms
(In reply to Juergen Harms from comment #4) > Checked rsync-3.1.0-4.1.mga4 on x86_64. The missing file now does exists, > rsyncd is correctly started if the rsyncd.socket had already been started > when the package is installed / upgraded. > > But when rsync-3.1.0-4.1 is installed from scratch (no rsyncd socket active > at the time of the install), it does not automatically start rsyncd, and > access to rsync from another machine then fails. The spec file probably > lacks a post install clause that enables/starts the socket. It's not missing, not all users will want the rsyncd service enabled just because the rsync package is installed, and in fact, most won't. As long as the service works when you enable rsyncd.socket, it's working as expected. Thanks for testing.
Whiteboard: (none) => MGA4-64-OK
I see your point - essentially a difference between installing rsync for use as a client, and for having a rsync server that does not require a permanent daemon. But, nevertheless, it is not satisfactory to have command-line activation as the only way for activating such an rsync server - this kind of "light service" is precisely the charm of the socket approach, and should become frequently required in small domestic LANs. The normal user does not even realise that this alternative exists. I see 2 easy alternatives: make the socket option accessible in a drakxx component (probably enhance drakservice with socket buttons), or add a small package - say "rsync-server" - that makes the socket operational. I would prefer the 2nd solution: to keep sockets as transparent components that come with packages and are not visible and do not require user interaction is a good concept. This is OT with repect to this bug. I think my test was thorough enough to serve as a QA OK. I will, later this day, install an i586 partion with where I can make the same test for i586.
Well, for some socket-activated services, drakxservices should expose them the same way it does with xinetd-based services, so it should allow you to enable rsyncd.socket (and *not* rsyncd.service) just as it used to when it ran through xinetd. I'm not sure exactly what the logic would be, as it shouldn't expose every .socket unit.
Confirmed that the updated package works correctly on Mageia 4 i586. This one can be validated.
> 2014-03-04 09:16:22 CET (Juergen Harms comment 6): will, later this day, install an i586 partion where I can make the same test for i586 > 2014-03-04 13:54:32 CET (David Walser comment 8): Confirmed that the updated package works correctly on Mageia 4 i586. This one can be validated. I have - 2 hour later - obtained the same result. This is precisely the principal reason why I stopped working for QA: even if it is only an hour to download the i586 iso, to install a system, to do the tests, it is an hour I had to steal elsewhere, and to insert into a tight schedule - and it is a demonstration that teamwork needs organisation and goodwill. Stop complaining that QA is short of people willing to contribute or that people walk away! Accidents - as bugs - will happen, but each kind should only happen once and than be fixed. Again OT, but needs to be said.
No, it did not need to be said. The fact that I also tested it does not invalidate your testing. Furthermore, since I'm the packager for this update, per QA policy I can't mark it as validated based on my testing alone. Your testing allows me to add the tag, so it was still helpful.
Whiteboard: MGA4-64-OK => MGA4-64-OK MGA4-32-OK
(In reply to Juergen Harms from comment #9) > I have - 2 hour later - obtained the same result. > > This is precisely the principal reason why I stopped working for QA Well, 1 person per arch to test an update is hardly enough. We don't enforce more in our policy because that would not be sustainable, but it is clearly not a loss of time when an extra tester confirms it works (or finds bugs the other tester hasn't found).
CC: (none) => stormi
(In reply to Juergen Harms from comment #9) > > 2014-03-04 09:16:22 CET (Juergen Harms comment 6): will, later this day, install an i586 partion where I can make the same test for i586 > > > 2014-03-04 13:54:32 CET (David Walser comment 8): Confirmed that the updated package works correctly on Mageia 4 i586. This one can be validated. > > I have - 2 hour later - obtained the same result. > > This is precisely the principal reason why I stopped working for QA: even if > it is only an hour to download the i586 iso, to install a system, to do the > tests, it is an hour I had to steal elsewhere, and to insert into a tight > schedule - and it is a demonstration that teamwork needs organisation and > goodwill. Stop complaining that QA is short of people willing to contribute > or that people walk away! Accidents - as bugs - will happen, but each kind > should only happen once and than be fixed. > > Again OT, but needs to be said. Perhaps we should all do the same thing then, and stop testing stuff until you can sort things out for us Juergen.
Advisory added to svn. Validating the update. Someone from the sysadmin team please push 12925.adv to updates.
Keywords: (none) => validated_updateWhiteboard: MGA4-64-OK MGA4-32-OK => MGA4-64-OK MGA4-32-OK advisoryCC: (none) => davidwhodgins, sysadmin-bugs
Update pushed: http://advisories.mageia.org/MGAA-2014-0076.html
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED