releng

#8080 rsync temporaries under /alt/risc-v
Closed: Insufficient data by syeghiay. Opened by tibbs.

Closed: Insufficient data
Reopen Issue

I've talked about this in IRC, but I figured I would open an issue for it.

Whatever process is responsible for copying content into /alt/risc-v does so by calling rsync without --delay-updates. This means that rsync temporaries can appear anywhere in that directory structure. These temporaries are world-readable, and so the file list generator will include them in the file listings of the mirror. So quick-fedora-mirror will try to copy them, and this causes a failure:

Looks like the file list is outdated.
rsync: link_stat "/alt/risc-v/repo/fedora/29/24607/src/Packages/i/.initial-setup-0.3.62-2.fc29.src.rpm.UQ5u2x" (in fedora-buffet0) failed: No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1659) [generator=3.1.3]
rsync failed; aborting run.
Will not check in or delete anything.

This seems to happen a couple of times a week, though of course it's quite random.

The simplest solution seems to me to be to call rsync with --delay-updates. This will make rsync store the temporaries in a directory named .~tmp~ which the file list generator and other rsync process should conveniently skip. It's much easier to skip one file with a weird name than it is to try and figure out what might be an rsync temporary. (Starts with a dot and ends with a dot followed by maybe six alphanumerics is the best we could do, which doesn't seem particularly safe.)

The "process" is the risc-v folks. ;)

Adding @rjones and @davidlt for comment...

I think davidlt is running this process. I've pinged him on IRC to make sure he sees this.

I have added "--delay-updates" to our rsync commands. Hopefully that improves the situation. I was also hoping to lower amount of data transferred by using "--link-dest=DIR", but the current attempts at it failed to provide expected results.

Thanks, folks. It was a sporadic issue so I'll have to wait a few days to verify that things are better.

--link-dest can help only in the limited circumstance that you already have a file tree on the destination host which is separate from but similar to the content you're copying. So if you wanted two copies of the tree, moved risc-v to risc-v-old and then added --link-dest risc-v-old when you copied. But of course you could just also use cp -rl first and not bother with --link-dest.

This cropped up yesterday:

rsync: link_stat "/alt/risc-v/repo/fedora/rawhide/24661/src/Packages/p/.python-xtermcolor-1.3-13.fc29.src.rpm.cdetmL" (in fedora-buffet0) failed: No such file or directory (2)

It wasn't there for long, but it does appear that temporaries are still being created. I'm not sure how that's possible if --delay-updates is used.

I checked and --delay-updates was used for this rsync. Maybe the order of the flags is affecting it? (couldn't find any comments about that in man page).

Metadata Update from @syeghiay:
- Issue tagged with: meeting

@mohanboddu will bring this up in this week's Releng meeting.

@tibbs Has it been fixed?

@rjones or @davidlt Can you give us the documentation of what and how to do these things?

Thanks.

We didn't have any mirror syncs recently (moving to new servers).

What kinda of documentation are you looking for?

@tibbs , is this still an issue? If so, please reopen.

Metadata Update from @syeghiay:
- Issue close_status updated to: Insufficient data
- Issue status updated to: Closed (was: Open)
Metadata
None

meeting

None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.