1

I am working on an embedded Linux system where busybox is being used as init.
I have 2 requirements on running my application.

  1. My application needs to start as early as possible;
  2. It needs to be managed by busybox (respawn if it exits).

Firstly, I started my application in /etc/inittab as follows,

# now run any rc scripts
::sysinit:/etc/init.d/rcS

# Put a getty on the serial port
#ttyS3::respawn:/sbin/getty -L  ttyS3 57600 vt100 # GENERIC_SERIAL
#no login
::respawn:/usr/bin/myapp
::respawn:-/bin/sh

In this way myapp is managed by busybox, when it exits, busybox will start it automatically.

But I found lots of services/daemons are started by /etc/init.d/rcS before starting myapp. this does NOT meet the 1st requirement.

I created /etc/init.d/S02myapp(which is started by /etc/init.d/rcS) to start my application in it, but it does not meet the 2nd requirement (I don't know if it is possible for busybox to manage the application started by rcS).

Then I got another way to meet both requirements as follows,

  1. Change /etc/init.d/S02myapp, to start another myapp.sh as a background process.
  2. Create myapp.sh, where it has a while-loop, in which myapp is started as foreground process.

With it myapp is started as early as possible (launched by rcS) and if it exits, the while-loop in myapp.sh will start it again.

I verified it worked, but I think this way is alittle ugly, for it shows something in ps ax as follows,

 1539 root      0:00 {myapp.sh} /bin/sh /etc/init.d/myapp.sh
 1544 root      0:00 /sbin/mdev -df
 1545 root      1:21 myapp

I am wondering if there is a clear way to satisfy my requirements for the application?

wangt13
  • 317
  • 1
  • 8

0 Answers0