The kernel log buffer can be configured to be bigger than 16 MiB. As the
user expects to see all available logs, do not arbitrarily constrain the
buffer size.
Signed-off-by: Jan Klötzke
---
util-linux/dmesg.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/util-linux/dmesg.c b/util-linux
Hi,
I posted a patch series for mdev almost a year ago:
http://lists.busybox.net/pipermail/busybox/2019-December/087675.html
It improves the reliability of the mdev daemon mode on busy systems.
Currently the daemon mode can silently fail and stop working! It would
be nice if it could be applie
On Thu, Sep 10, 2020 at 07:19:32AM +0200, Leonid Zhigunov wrote:
> There was, of course, nothing wrong with MDEV!
> It is my head and hands to blame!
> And text editors, none of wich showed the newline
> im mdev.conf. Only after opening it in hex editor
> I spotted 0D 0A there!
Glad you found the
On Thu, Dec 19, 2019 at 09:11:01PM +, Laurent Bercot wrote:
>
> > Overcommit is disabled:
> >
> > / # cat /proc/sys/vm/overcommit_memory
> > 2
>
> That doesn't mean overcommit is disabled. That means it's enabled with
> a hard limit. What was overcommit_ratio?
I've left it at the default of
On Wed, Dec 18, 2019 at 09:34:39PM +0100, Bernhard Reutner-Fischer wrote:
> On 17 December 2019 17:06:46 CET, "Jan Klötzke" wrote:
> >On Tue, Dec 17, 2019 at 12:01:09AM +, Laurent Bercot wrote:
> >>
> >> > The socket receive buffer turned out to be
On Tue, Dec 17, 2019 at 12:01:09AM +, Laurent Bercot wrote:
>
> > The socket receive buffer turned out to be too small for real world
> > systems. Use the same size as udevd to be on the safe side. As this is
> > just a limit and the memory is not allocated by the kernel until really
> > neede
foreground due to -f, the messages are still written
to stderr as before.
Signed-off-by: Jan Klötzke
---
util-linux/mdev.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/util-linux/mdev.c b/util-linux/mdev.c
index 91c4ff466..1ef7a029e 100644
--- a/util
When rules are caches from mdev.conf then their line number cannot be
retrieved from the parser anymore. Instead store the line number in the
rule so that a cached rule still shows the line number where it was
coming from.
Signed-off-by: Jan Klötzke
---
util-linux/mdev.c | 9 -
1 file
The socket receive buffer turned out to be too small for real world
systems. Use the same size as udevd to be on the safe side. As this is
just a limit and the memory is not allocated by the kernel until really
needed there is actually no memory wasted.
Signed-off-by: Jan Klötzke
---
util-linux
Like a well behaved daemon the reception of SIGHUP triggers a reload of
/etc/mdev.conf. The file is parsed immediately to catch any errors early
and to cache the current version.
Signed-off-by: Jan Klötzke
---
util-linux/mdev.c | 106 +-
1 file
: Jan Klötzke
---
util-linux/mdev.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/util-linux/mdev.c b/util-linux/mdev.c
index 1ef7a029e..671221af5 100644
--- a/util-linux/mdev.c
+++ b/util-linux/mdev.c
@@ -81,7 +81,7 @@
//kbuild:lib-$(CONFIG_MDEV) += mdev.o
It looks like the mdev daemon mode is not fully reliable (see [1]). This
patch series improves it by first increasing the netlink buffer size and
by adding an error handling in case of socket overflows.
During discussion a number of other related issues popped up. These are
fixed in the series too
Signed-off-by: Jan Klötzke
---
util-linux/mdev.c | 44 +++-
1 file changed, 27 insertions(+), 17 deletions(-)
diff --git a/util-linux/mdev.c b/util-linux/mdev.c
index 4e3299d22..cfc1a38bc 100644
--- a/util-linux/mdev.c
+++ b/util-linux/mdev.c
@@ -1172,6
As soon as the socket is bound it will receive messages. Make sure the
recieve buffer size is increased before the first message is received.
Signed-off-by: Jan Klötzke
---
libbb/xconnect.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/libbb/xconnect.c b
If the netlink read() failed with ENOBUFS we know that we have missed at
least one message due to a socket receive buffer overrun. The only way
how to recover is to drop the old socket, open a fresh one and make a
cold-plug scan of the current system state.
Signed-off-by: Jan Klötzke
---
util
On Mon, Dec 16, 2019 at 04:53:32PM +1000, Alexander Zangerl wrote:
> On Sun, 15 Dec 2019 22:15:21 +0100, Jan Klötzke writes:
> >On Sun, Dec 15, 2019 at 08:44:14AM +1000, Alexander Zangerl wrote:
> >> i only increased BUFFER_SIZE.
> ...
> >This is strange. The read() call will always return a singl
On Sun, Dec 15, 2019 at 08:44:14AM +1000, Alexander Zangerl wrote:
> On Sat, 14 Dec 2019 14:49:20 +0100, Jan Klötzke writes:
> >Just to double check: did you increase BUFFER_SIZE or RCVBUF? I'm
> >asking because the error that you observed (ENOBUFS) is returned by the
> &g
On Sat, Dec 14, 2019 at 06:47:43PM +1000, Alexander Zangerl wrote:
> the mdev -d daemon mode introduced in 1.31.0 works pretty well on
> my (systemd- and udev-less) box, but i've hit a few minor issues:
>
> 1. after a few days the mdev daemon tends to die.
>
> this is on a laptop that suspends an
On Mon, Oct 28, 2019 at 07:26:10AM +0100, Joerg Vehlow wrote:
>
>
> Am 23.10.2019 um 20:39 schrieb Stefan Seyfried:
> > Am 22.10.19 um 10:49 schrieb Joerg Vehlow:
> > > No interest in util-linux compatibility?
> > Is util-linux really creating the device node?
> >
> > I thought it would use the
Adds the -d option to run mdev in daemon mode handling hotplug events
from the kernel like udev. If the system generates many hotplug events
this mode of operation will consume less resources than registering
mdev as hotplug helper or using the uevent applet.
Signed-off-by: Jan Klötzke
---
v2
On Sat, May 04, 2019 at 07:00:30PM +0200, Markus Gothe wrote:
> Ouch, then fork()'ing is indeed an issue. And Linux not being an RTOS is
> another issue, but I hope you are using an RTOS (like QNX or FreeRTOS) and
> not Linux.
Oh, Linux is actually a better match for a full blown IVI system, at
On Sat, May 04, 2019 at 07:42:06AM +, Laurent Bercot wrote:
>
> > If mdev is used as kernel hotplug helper and the system generates many
> > hotplug events it will quickly consume considerable resources because a
> > process is forked for each event and, if the mdev.seq feature is used,
> > th
On Fri, May 03, 2019 at 11:16:34PM +0200, Markus Gothe wrote:
> Err, zram ofc :)
...
>
> Or even better you could turn on zswap on your embedded device and avoid the
> OOM-kiler which I guess is the real reason you fixed this.
Actually RAM was not the problem at all. It really was the time to sp
On Sat, May 04, 2019 at 08:06:44AM +0200, Peter Korsgaard wrote:
> >>>>> "Jan" == Jan Klötzke writes:
>
> > Adds the -s option to run mdev in daemon mode handling hotplug events
> > from the kernel like udev. If the system generates many hotplug even
Signed-off-by: Jan Klötzke
---
util-linux/mdev.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/util-linux/mdev.c b/util-linux/mdev.c
index 8205a260a..9e2f527d7 100644
--- a/util-linux/mdev.c
+++ b/util-linux/mdev.c
@@ -249,6 +249,10 @@
#endif
+enum
This purely moves code from main() to separate functions for better
extensibility.
Signed-off-by: Jan Klötzke
---
util-linux/mdev.c | 154 --
1 file changed, 82 insertions(+), 72 deletions(-)
diff --git a/util-linux/mdev.c b/util-linux/mdev.c
index
If mdev is used as kernel hotplug helper and the system generates many
hotplug events it will quickly consume considerable resources because a
process is forked for each event and, if the mdev.seq feature is used,
they must also coordinate among each other. While the uevent applet
mitigates some of
Adds the -s option to run mdev in daemon mode handling hotplug events
from the kernel like udev. If the system generates many hotplug events
this mode of operation will consume less resources than registering
mdev as hotplug helper or using the uevent applet.
Signed-off-by: Jan Klötzke
---
util
28 matches
Mail list logo
