Re: apt-cacher errors
On Mon, Mar 25, 2019 at 02:24:22PM +, Adam Weremczuk wrote: > Any practical difference between \*wheezy\* and '*wheezy*' in this case? Both forms of quoting yield identical results. As does "*wheezy*".
Re: apt-cacher errors
Hi Greg,
Thank you for taking the time to point out all the shortcomings.
On 25/03/19 13:21, Greg Wooledge wrote:
On Mon, Mar 25, 2019 at 12:11:21PM +, Adam Weremczuk wrote:
I've found 30 entries referencing wheezy and removed them all:
sudo find /var/cache/apt-cacher/ -type f -name *wheezy* | xargs rm
sudo find /var/cache/apt-cacher -type f -name '*wheezy*' -delete
There are three mistakes in your command:
1) The glob must be quoted, or the shell will expand it based on the files
in the current working directory, wherever that happens to be.
I would normally use \*wheezy\* but I new that wouldn't make any
difference as I saw the list earlier.
Any practical difference between \*wheezy\* and '*wheezy*' in this case?
2) xargs without -0 is unsafe to use for filenames, because they may contain
whitespace or single quotes or double quotes, all of which are special
to xargs.
Again, I saw the list so didn't bother but a fair point indeed, it could
easily fail or even turn disastrous.
3) You ran find with sudo privileges (probably not necessary), and failed
to run the rm with sudo privileges. All of the removals are therefore
going to fail.
TBH I run it as root and added single sudo in front after pasting not to
promote bad practices :)
You might argue that "apt-cacher never has any files with spaces!"
That may be true. But it's still a good habit to develop. Also, -delete
is more efficient than | xargs rm, albeit not portable to POSIX scripts.
Never used it with find, good to know.
If you want it to be portable as well as safe, then:
sudo find /var/cache/apt-cacher -type f -name '*wheezy*' -exec rm {} +
That's less efficient than -delete, but it's the best you can do if
POSIX portability is required.
Agree.
Thanks again,
Adam
Re: apt-cacher errors
On 3/25/19 9:21 AM, Greg Wooledge wrote:
On Mon, Mar 25, 2019 at 12:11:21PM +, Adam Weremczuk wrote:
I've found 30 entries referencing wheezy and removed them all:
sudo find /var/cache/apt-cacher/ -type f -name *wheezy* | xargs rm
sudo find /var/cache/apt-cacher -type f -name '*wheezy*' -delete
There are three mistakes in your command:
1) The glob must be quoted, or the shell will expand it based on the files
in the current working directory, wherever that happens to be.
2) xargs without -0 is unsafe to use for filenames, because they may contain
whitespace or single quotes or double quotes, all of which are special
to xargs.
3) You ran find with sudo privileges (probably not necessary), and failed
to run the rm with sudo privileges. All of the removals are therefore
going to fail.
You might argue that "apt-cacher never has any files with spaces!"
That may be true. But it's still a good habit to develop. Also, -delete
is more efficient than | xargs rm, albeit not portable to POSIX scripts.
If you want it to be portable as well as safe, then:
sudo find /var/cache/apt-cacher -type f -name '*wheezy*' -exec rm {} +
That's less efficient than -delete, but it's the best you can do if
POSIX portability is required.
Great thoughts Greg.
Helped me too.
Re: apt-cacher errors
On Mon, Mar 25, 2019 at 12:11:21PM +, Adam Weremczuk wrote:
> I've found 30 entries referencing wheezy and removed them all:
>
> sudo find /var/cache/apt-cacher/ -type f -name *wheezy* | xargs rm
sudo find /var/cache/apt-cacher -type f -name '*wheezy*' -delete
There are three mistakes in your command:
1) The glob must be quoted, or the shell will expand it based on the files
in the current working directory, wherever that happens to be.
2) xargs without -0 is unsafe to use for filenames, because they may contain
whitespace or single quotes or double quotes, all of which are special
to xargs.
3) You ran find with sudo privileges (probably not necessary), and failed
to run the rm with sudo privileges. All of the removals are therefore
going to fail.
You might argue that "apt-cacher never has any files with spaces!"
That may be true. But it's still a good habit to develop. Also, -delete
is more efficient than | xargs rm, albeit not portable to POSIX scripts.
If you want it to be portable as well as safe, then:
sudo find /var/cache/apt-cacher -type f -name '*wheezy*' -exec rm {} +
That's less efficient than -delete, but it's the best you can do if
POSIX portability is required.
Re: apt-cacher errors
I've found 30 entries referencing wheezy and removed them all: sudo find /var/cache/apt-cacher/ -type f -name *wheezy* | xargs rm which appears to have fixed the issue. Thanks, Adam On 25/03/19 11:43, Roberto C. Sánchez wrote: On Mon, Mar 25, 2019 at 07:05:11AM -0400, Roberto C. Sánchez wrote: On Mon, Mar 25, 2019 at 08:59:40AM +, Adam Weremczuk wrote: Hi all, On 24th March (last Sunday) I received the following (for the first time): Subject: Cron test -x /usr/share/apt-cacher/apt-cacher-cleanup.pl && /usr/share/apt-cacher/apt-cacher-cleanup.pl Error: cannot open ../headers/debian_dists_wheezy_Release for locking: No such file or directory Failed to open filehandles for debian_dists_wheezy_Release. Resolve this manually. Exiting to prevent deletion of cache contents. The above all came from systems originally running wheezy which were upgraded to stretch about 2 years ago. Questions: 1. How to get rid of these errors? I would prefer to avoid spending half a day deciphering a chain of Perl scripts which I'm not familiar with. 2. What specifically happened last week to trigger this behavior? Was it e.g. a permanent removal of all wheezy repos and references? https://lists.debian.org/debian-devel-announce/2019/03/msg6.html You will need to change your sources.list. http://archive.debian.org/debian/README Perhaps I spoke too soon. I encountered this error in my apt-cacher-ng log after replying to your message. Checking/Updating debrep/dists/wheezy/Release... Attempting to download the alternative version... Checking/Updating debrep/dists/wheezy/InRelease... 404 Not Found After seeing that I re-read your message and noticed that the system had been initially installed as wheezy but now runs stretch. It has been some years since I moved to apt-cacher-ng, so I've forgotten how it differs from apt-cacher, but in my case I had to remove the directories /var/cache/apt-cacher-ng/debrep/dists/wheezy* and then re-run the expiration task. You may need to do something similar. Regards, -Roberto
Re: apt-cacher errors
On Mon, Mar 25, 2019 at 07:05:11AM -0400, Roberto C. Sánchez wrote: > On Mon, Mar 25, 2019 at 08:59:40AM +, Adam Weremczuk wrote: > > Hi all, > > > > On 24th March (last Sunday) I received the following (for the first time): > > > > Subject: Cron test -x /usr/share/apt-cacher/apt-cacher-cleanup.pl && > > /usr/share/apt-cacher/apt-cacher-cleanup.pl > > > > Error: cannot open ../headers/debian_dists_wheezy_Release for locking: No > > such file or directory > > Failed to open filehandles for debian_dists_wheezy_Release. Resolve this > > manually. > > Exiting to prevent deletion of cache contents. > > > > The above all came from systems originally running wheezy which were > > upgraded to stretch about 2 years ago. > > > > Questions: > > > > 1. How to get rid of these errors? I would prefer to avoid spending half a > > day deciphering a chain of Perl scripts which I'm not familiar with. > > 2. What specifically happened last week to trigger this behavior? Was it > > e.g. a permanent removal of all wheezy repos and references? > > > https://lists.debian.org/debian-devel-announce/2019/03/msg6.html > > You will need to change your sources.list. > > http://archive.debian.org/debian/README > Perhaps I spoke too soon. I encountered this error in my apt-cacher-ng log after replying to your message. Checking/Updating debrep/dists/wheezy/Release... Attempting to download the alternative version... Checking/Updating debrep/dists/wheezy/InRelease... 404 Not Found After seeing that I re-read your message and noticed that the system had been initially installed as wheezy but now runs stretch. It has been some years since I moved to apt-cacher-ng, so I've forgotten how it differs from apt-cacher, but in my case I had to remove the directories /var/cache/apt-cacher-ng/debrep/dists/wheezy* and then re-run the expiration task. You may need to do something similar. Regards, -Roberto -- Roberto C. Sánchez
Re: apt-cacher errors
On Mon, Mar 25, 2019 at 08:59:40AM +, Adam Weremczuk wrote: > Hi all, > > On 24th March (last Sunday) I received the following (for the first time): > > Subject: Cron test -x /usr/share/apt-cacher/apt-cacher-cleanup.pl && > /usr/share/apt-cacher/apt-cacher-cleanup.pl > > Error: cannot open ../headers/debian_dists_wheezy_Release for locking: No > such file or directory > Failed to open filehandles for debian_dists_wheezy_Release. Resolve this > manually. > Exiting to prevent deletion of cache contents. > > The above all came from systems originally running wheezy which were upgraded > to stretch about 2 years ago. > > Questions: > > 1. How to get rid of these errors? I would prefer to avoid spending half a > day deciphering a chain of Perl scripts which I'm not familiar with. > 2. What specifically happened last week to trigger this behavior? Was it e.g. > a permanent removal of all wheezy repos and references? > https://lists.debian.org/debian-devel-announce/2019/03/msg6.html You will need to change your sources.list. http://archive.debian.org/debian/README Regards, -Roberto -- Roberto C. Sánchez
apt-cacher errors
Hi all, On 24th March (last Sunday) I received the following (for the first time): Subject: Cron test -x /usr/share/apt-cacher/apt-cacher-cleanup.pl && /usr/share/apt-cacher/apt-cacher-cleanup.pl Error: cannot open ../headers/debian_dists_wheezy_Release for locking: No such file or directory Failed to open filehandles for debian_dists_wheezy_Release. Resolve this manually. Exiting to prevent deletion of cache contents. The above all came from systems originally running wheezy which were upgraded to stretch about 2 years ago. Questions: 1. How to get rid of these errors? I would prefer to avoid spending half a day deciphering a chain of Perl scripts which I'm not familiar with. 2. What specifically happened last week to trigger this behavior? Was it e.g. a permanent removal of all wheezy repos and references? Regards, Adam
