Afaik, running a daemon in foreground mode and instructing start-stop-daemon to 
background it is common practice if the daemon doesn’t support writing a 
pidfile itself, so start-stop-daemon can handle it itself. Without using 
foregrounded process + -b, it wouldn’t know the resulting process id. If 
busybox mdev supports a pidfile, this wouldn’t be necessary.

--
Christopher “kergoth” Larson
chris_lar...@mentor.com, chris.lar...@siemens.com, kerg...@gmail.com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics, a Siemens Business
On Dec 17, 2020, 4:59 PM -0700, Andre McCurdy <armccu...@gmail.com>, wrote:
> On Thu, Dec 17, 2020 at 2:54 PM Khem Raj <raj.k...@gmail.com> wrote:
> >
> > When busybox is used for device management, kernel needs to support
> > older/obsolete mechanism via CONFIG_UEVENT_HELPER and
> > CONFIG_UEVENT_HELPER_PATH to enable /proc/sys/kernel/hotplug but this
> > would require kernel defconfig change and will always be needed when
> > mdev is used, intead run it in daemon mode
> >
> > Update mdev init script to run mdev in daemon mode
> >
> > Signed-off-by: Khem Raj <raj.k...@gmail.com>
> > ---
> > meta/recipes-core/busybox/busybox/mdev.cfg | 2 +
> > meta/recipes-core/busybox/files/mdev | 56 +++++++++++++++-------
> > 2 files changed, 41 insertions(+), 17 deletions(-)
> >
> > diff --git a/meta/recipes-core/busybox/busybox/mdev.cfg 
> > b/meta/recipes-core/busybox/busybox/mdev.cfg
> > index 6aefe90e43..143e6097cb 100644
> > --- a/meta/recipes-core/busybox/busybox/mdev.cfg
> > +++ b/meta/recipes-core/busybox/busybox/mdev.cfg
> > @@ -9,3 +9,5 @@ CONFIG_SETSID=y
> > CONFIG_CTTYHACK=y
> >
> > CONFIG_FEATURE_SHADOWPASSWDS=y
> > +CONFIG_FEATURE_XARGS_SUPPORT_ZERO_TERM=y
> > +CONFIG_FEATURE_MDEV_DAEMON=y
> > diff --git a/meta/recipes-core/busybox/files/mdev 
> > b/meta/recipes-core/busybox/files/mdev
> > index 8c9c06e96c..2fbdfb073e 100755
> > --- a/meta/recipes-core/busybox/files/mdev
> > +++ b/meta/recipes-core/busybox/files/mdev
> > @@ -1,21 +1,43 @@
> > #!/bin/sh
> > -mount -t proc proc /proc
> > -mount -t sysfs sysfs /sys
> > -mount -t tmpfs tmpfs /dev -o size=64k,mode=0755
> > -mkdir /dev/pts /dev/shm
> > -chmod 777 /dev/shm
> > -mount -t devpts devpts /dev/pts
> > -touch /dev/mdev.seq
> > -#sysctl -w kernel.hotplug=/sbin/mdev
> > -echo "/sbin/mdev" > /proc/sys/kernel/hotplug
> > -mdev -s
> > -
> > #
> > -# We might have mounted something over /dev, see if /dev/initctl is there.
> > +# Run the mdev daemon
> > #
> > -if test ! -p /dev/initctl
> > -then
> > - rm -f /dev/initctl
> > - mknod -m 600 /dev/initctl p
> > -fi
> > +
> > +DAEMON="mdev"
> > +PIDFILE="/var/run/$DAEMON.pid"
> > +
> > +
> > +start() {
> > + echo -n "Starting $DAEMON... "
> > + start-stop-daemon -S -b -m -p $PIDFILE -x /sbin/mdev -- -df
>
> Where do these start-stop-daemon options come from? Using -b for an
> application which is designed to run as a daemon (and deliberately
> telling that app to run in the foreground) looks odd, etc.
>
> Are there bugs or limitations in mdev which you are trying to workaround?
>
> > + [ $? -eq 0 ] && echo "OK" || echo "ERROR"
> > +
> > + # coldplug modules
> > + find /sys/ -name modalias -print0 | \
> > + xargs -0 sort -u | \
> > + tr '\n' '\0' | \
> > + xargs -0 modprobe -abq
> > +}
> > +
> > +stop() {
> > + echo -n "Stopping $DAEMON... "
> > + start-stop-daemon -K -p $PIDFILE
> > + [ $? -eq 0 ] && echo "OK" || echo "ERROR"
> > +}
> > +
> > +restart() {
> > + stop
> > + start
> > +}
> > +
> > +case "$1" in
> > + start|stop|restart)
> > + "$1"
> > + ;;
> > + *)
> > + echo "Usage: $0 {start|stop|restart}"
> > + exit 1
> > +esac
> > +
> > +exit $?
> >
> > --
> > 2.29.2
> >
> >
> >
> >
>
>
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145838): 
https://lists.openembedded.org/g/openembedded-core/message/145838
Mute This Topic: https://lists.openembedded.org/mt/79049549/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to