Can the bug fix be applied for Ubuntu 21.04? Please.
On slow machines like a Raspberry 4 with stack limit 50 (Ubuntu
20.10), a single pgrep call takes 17 seconds!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launch
Public bug reported:
All invocations of run-this-one are slowed down massively (since Ubuntu
20.04, also in Ubuntu 20.10). Example:
time run-this-one echo
real 1,902s user 1,216s syst 0,182s busy 73,47%
The slow down depends on the stack size of your shell. So, this is
probably caused by the
** Tags added: hirsute
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1874824
Title:
pgrep reports error "cannot allocate" when run without stack limit
To manage notifications about this bug go to:
Thanks for such a quick and helpful response.
Which Ubuntu version did you try and which stack limits?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1917157
Title:
run-this-one is very slow
To man
There are many programming languages where some frequent programming
patterns (like non tail recursion) use more stack than the default of
8192. People normally increase the stack limit in such cases, e.g.
# ulimit -S -s 80
The run time increase is linear in stack limit:
# time run-this-on
Sure, fixing the pgrep bug will be the easiest solution for run-this-one
and others. Thanks for your help on bug 1878424.
Let's hope it will be in 21.04 and maybe even backported.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https:
I meant bug 1874824.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1917157
Title:
run-this-one is very slow
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/r
My affected system is an ASUS Zenbook UX305FA with Secure Boot turned off.
Thanks for all the hints, especially comment #10. My workaround was easy:
1. In grub menu, choose an entry and edit it (key press: e).
2. Add rmmod tpm in a line before the first insmod.
3. Boot with the modified entry (key
The bug fix is almost 3 years old. Can anybody apply it?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1761557
Title:
Qualcom QCA6174 - regdomain: 0x5f
To manage notifications about this bug go to:
Even worse for Ubuntu 20.10 (procps 2:3.3.16-5ubuntu2). With a stack
limit of 50, almost 11 seconds for a simple pgrep; without
stacklimit, immediate crash.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net
I tested procps/groovy-proposed,now 2:3.3.16-5ubuntu2.1 amd64. I have
repeated pgrep and pkill commands that caused the bug before. They do
work with the proposed package.
** Tags removed: verification-needed-groovy
** Tags added: verification-done-groovy
--
You received this bug notification b
Archlinux fixed this bug today, now in testing stage. Any news for
Ubuntu?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1874824
Title:
pgrep reports error "cannot allocate" when run without stack l
I installed procps-ng 3.3.16.49-ae4a myself on all our Ubuntu 20.04
computers. This fixed both problems, slow pgrep / pkill and crashing
pgrep / pkill.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/187
The Arch Linux fix appeared in Manjaro. I can confirm that it works on
Manjaro machines.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1874824
Title:
pgrep reports error "cannot allocate" when run w
Public bug reported:
If you have no stack limit (ulimit -S -s unlimited), any pgrep call will
fail with an error:
> pgrep vim
pgrep: cannot allocate 4611686018427387903 bytes
If you have a high stack limit (e.g. ulimit -S -s 50), pgrep is very
slow:
> time pgrep vim
2196
real 8.48s user 8.4
For the unlimited case, there is also Debian bug #955697
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955697
Those bug reports do not mention the massive slowdown linear in stack limit.
** Bug watch added: Debian Bug tracker #955697
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=95569
The problem is the same for other popular tools like pkill from the same
package.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1874824
Title:
pgrep reports error "cannot allocate" when run without
Public bug reported:
The error message is "no process found". If I shorten the name of the
binary to 15 characters, killall works as before. The change was
introduced by Ubuntu 19.04.
Example:
# server_with_16ch &
# killall server_with_16ch
server_with_16ch: no process found
** Affects: psmisc
To which version of psmisc should the patch be backported?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1827467
Title:
killall does not find processes with names longer than 15
To manage notificat
Tethering works for me on Nexus 4 with OTA-13. (Some steps from my
recipe in comment 8 are even redundant now; let me know if you need
details.)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1427697
T
Hi.
The relevant line in the kern.log of the affected server
(4.10.0-21-generic) was:
kernel BUG at /build/linux-
lz1RHE/linux-4.10.0/include/linux/swapops.h:129!
I switched to the 4.11 mainline kernel:
Linux 4.11.2-041102-generic #201705201036 SMP Sat May 20 14:38:21 UTC 2017
x86_64 x86_64 x86
Almost ten years of quite constant development has also closed some security
holes, e.g.
https://github.com/gambit/gambit/commit/054baf3e4185467ea9984083320c7e36f6b09486
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.lau
This fast log filling is also present on Ubuntu 16.04.
If there is no bug fix, are there any workarounds?
Thanks for your time.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1550228
Title:
sinfod wr
I am now using this work-around, but I think that the achieved behavior
should be the default.
1. Add the following line to /lib/systemd/system/sinfo.service, below the
ExecStart line:
StandardOutput=null
2. systemctl daemon-reload && systemctl restart sinfo
Ciao
Sven
--
You received this bug
Here is an updated version of John's recipe (comment 5) for fixing wired
tethering!
Worked on standard image for Nexus 4 (and Ubuntu 15.04 or 15.10 on computer).
Prerequisites for your phone:
- Turn on developer mode: "System settings" | "About this phone" | "Developer
mode"
- Make the OS image
I have successfully repeated the fix for the current OTA version
and recorded my experience in a new comment:
https://bugs.launchpad.net/ubuntu/+source/dbus-property-
service/+bug/1427697/comments/8
Wired tethering still works for Nexus 4!
--
You received this bug notification because you are a
André, I think you are not the only one disappointed ...
But there was a (wired) tethering solution, that I confirmed 2 months ago
(haven't tried on newer OTA versions):
https://bugs.launchpad.net/ubuntu/+source/dbus-property-service/+bug/1427697
more specifically:
https://bugs.launchpad.net/ub
Public bug reported:
sinfod (version 0.0.47-4, Ubuntu 15.10) fills /var/log/syslog very quickly.
Is this normal?
Can this be reduced?
Example lines:
Feb 26 08:00:11 s16 sinfod[936]: BroadcastReceiver::handle_receive_from 370
bytes
Feb 26 08:00:11 s16 sinfod[936]: BroadcastReceiver::receive
Feb 2
24.04 and 23.10 are affected, while 22.04 is ok.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2036283
Title:
i386 glibc is missing fmod in libm.a
To manage notifications about this bug go to:
http
This is Debian bug https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=1070872 which is already fixed in glibc 2.38-11
** Bug watch added: Debian Bug tracker #1070872
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070872
--
You received this bug notification because you are a member of Ubu
30 matches
Mail list logo
