This bug was fixed in the package apt - 1.0.1ubuntu2.18
---
apt (1.0.1ubuntu2.18) trusty; urgency=medium
* ExecFork: Use /proc/self/fd to determine which files to close
(Closes: #764204) (LP: #1332440).
-- Julian Andres Klode Mon, 09 Apr 2018 15:32:09
+0200
** Changed in: a
I have verified that none of these failures are regressions; they all
appear in previous apt uploads/run against other triggers too.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1332440
Title:
apt-
There are some dep8 regressions reported in http://people.canonical.com
/~ubuntu-archive/pending-sru.html. I've requested some retries. If
they're still failing, please could you take a look?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubu
Verified. (BTW, I aborted the initial run as it simply took too long so
actual numbers would have been much higher)
root@t:~# apt-cache policy libapt-pkg4.12
libapt-pkg4.12:
Installed: 1.0.1ubuntu2.17
Candidate: 1.0.1ubuntu2.18
Version table:
1.0.1ubuntu2.18 0
500 http://archiv
Time for apt-cache policy apt also decreased from 1.86 seconds to 0.04
seconds :)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1332440
Title:
apt-get update very slow when ulimit -n is big
To mana
Hello tom916, or anyone else affected,
Accepted apt into trusty-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/apt/1.0.1ubuntu2.18 in
a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://wiki.ubu
** Description changed:
[Impact]
apt is slow at spawning subprocesses, as it calls fcntl() on each file
descriptor, causing significant slowdown. On my container:
0.71user 1.26system 0:01.98elapsed 99%CPU (0avgtext+0avgdata
34164maxresident)k
0.14user 0.05system 0:00.20elapsed 99%
This was fixed in 1.0.10 or something, and I just uploaded a fixed
version to trusty (1.0.1ubuntu2.18).
** Description changed:
+ [Impact]
+ apt is slow at spawning subprocesses, as it calls fcntl() on each file
descriptor, causing significant slowdown. On my container:
+
+ 0.71user 1.26system
** Also affects: apt (Ubuntu Trusty)
Importance: Undecided
Status: New
** Changed in: apt (Ubuntu Trusty)
Status: New => Triaged
** Changed in: apt (Ubuntu Trusty)
Assignee: (unassigned) => Julian Andres Klode (juliank)
--
You received this bug notification because you are
** Changed in: apt (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1332440
Title:
apt-get update very slow when ulimit -n is big
To manage notificati
Apologies, I retract that -- looks like the issue was related to MTU and
PMTU discovery.. It just happened that the machines with the mtu issues
were also the ones with huge ulimits configured.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to U
I'm still seeing this as a problem (I think) on Ubuntu 15.10 Wily,
kernel 4.2.0-25-generic.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1332440
Title:
apt-get update very slow when ulimit -n is bi
When running Ubuntu 14.04 inside Docker I've seen this issue with CentOS
as well:
CentOS 7.2
3.10.0-327.4.4.el7.x86_64
I tested a few kernels with Ubuntu 14.04 as host OS and I found:
apt-get update extremely slow on kernels:
3.13.0-76
3.13.0-65
3.13.0-30
3.13.0-29
apt-get update fast on kerne
Yep, it's not fixed:
~ λ docker run --rm ubuntu:14.04 bash -c 'ulimit -n 50 && apt-get install
strace && strace -c -f apt-get update'
Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
strace
0 upgraded, 1 newly in
If it's been fixed, I don't know what in. This still appears to be an
issue for me. If I've failed to apply some update that fixed it, I'd
love to know what it was.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad
Looks like it was fixed in some update. Can anyone confirm that?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1332440
Title:
apt-get update very slow when ulimit -n is big
To manage notifications
I can also confirm this running docker with the library/ubuntu:14.04
image on a virtualbox host running ubuntu 14.04
running apt-get update times out or takes an extremely long time.
Host Virtualbox:
$ ulimit -n
1024
docker container:
root@1518e024f53a:/# ulimit -n
524288
root@1518e024f53a:/#
Running apt-get update takes ~80 seconds for me running:
* Virtualbox 4.3.12
* Ubuntu 14.04 LTS 64 bit desktop (3.13.0-30-generic #55-Ubuntu SMP)
* Docker version 1.0.1, build 990021a
* Official 'ubuntu:14.04' docker image
In the VirtualBox machine it takes < 10s
Running a similar setup in VMwar
Same problem with Docker containers, apt-get update take forever or just
fails.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1332440
Title:
apt-get update very slow when ulimit -n is big
To manage
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: apt (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1332440
Title:
apt-ge
Building docker image with ulimit -n 500k takes literally forever in
virtualbox. Iterating 500k fds that are not even open on every fork in
apt (and there are many of them) is not okay.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
h
@ seth-arnold
I set ulimit 256 on my machine,here is the test.
My question is Why in new version of apt-get,it's must check file
descriptors?
root@dev2:~# ulimit -n 256
root@dev2:~# time apt-get update > /dev/null
real0m32.587s
user0m19.211s
sys 0m11.127s
root@dev2:~# uli
Setting 100,000 file descriptors to close-on-exec while re-checking the
limits each iteration takes 0.092 seconds on my laptop.
Just how large did you set your ulimits?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.laun
Thanks for taking the time to report this bug and helping to make Ubuntu
better. We appreciate the difficulties you are facing, but this appears
to be a "regular" (non-security) bug. I have unmarked it as a security
issue since this bug does not show evidence of allowing attackers to
cross privile
24 matches
Mail list logo
