Re: Synaptic error
On 4/12/20, tomas@tuxteam.de <tomas@tuxteam.de> wrote:
> On Sun, Apr 12, 2020 at 08:43:12AM -0500, Richard Owlett wrote:
>> Using Synaptic I:
>> 1. searched package names for "info"
>> 2. selected it
>> 3. clicked Apply
>> 4. received error message saying
>> >E: Could not open lock file /var/cache/apt/archives/lock - open (2: No
>> > such file or directory)
>> >E: Could not open file descriptor -1
>> >E: Unable to lock the download directory
>
> Question: is there a /var/cache/apt/archives directory? There should
> be one.
DISCLAIMER: I see Reco's very succinct answer. Kudos! I decided to
still send mine out. Maybe it will help a newbie somewhere get to know
their own system better somehow. I can still remember the first time
of TRUSTING command line package management. Major YEEHAW! moment in
my Linux usage overall. I've never looked back. :)
So my observation to this thread is........
Maybe this is a Synaptic thing that it doesn't work when that lock's
missing AND that it doesn't recreate that lock file on the fly?
As tomas asked, what about... looking first to see if there actually
is that file in place to see if it's falsely being reported as
missing? (Sounds like that's a done deal.)
Then, if it really *is* missing: What *I* would try since I've been in
this spot in various similarly different scenarios is run something
like "apt(-get) upgrade".
That command might easily put that file back in place. It did for me
just now. That command then stops and waits for user interaction. The
action can be cancel(l)ed without any further system changes
occurring.
The reason I know to try that is because that lock file and the ones
at "/var/lib/dpkg/lock" and "/var/lib/dpkg/lock-frontend" will, on
rare occasion, get locked up for whatever reasons. If I "delete" those
by renaming so they're still available as backup then rerun an
affected apt(-get) command, things go back to normal when dpkg and/or
apt(-get) recreate those lock files on the fly.
It's odd to me that Synaptic's not replacing a missing lock file, but
it may be on purpose by Developer design. Or maybe Synaptic doesn't
"know how" to do that... or doesn't have the right permissions reach
deeper into the system or something... ?
It occurred to me to check the dotDEB archive files for both dpkg and
apt since I experience this with both of them. Nope, neither package
contains those files as part of their base installation. Rightly or
wrongly, that causes me to a-sume those lock files are generated on
the fly, at least on the first run of a program after installation..
OR in instances such as my experiences where I have to force the
situation via lock file deletion WHEN my setup... locks up for
whatever reason.
To test that theory, I just ran "apt-get update", and those three
files maintained their previous creation time stamps that are at least
an hour old... or two days old because I JUST encountered this with
dpkg a couple days ago (TWICE). That implies to me that they're
initially generated then stand their ground in that creation state
until borked again at some future point in time.
Cindy :)
--
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA
* hops with birdseed *
Reply to: