[Buildroot] buggy init script

[Buildroot] buggy init script

[Kenneth Adam Miller]

I have a buildroot system with multiple target bzImages, each with a
respective configuration. The configurations don't differ in much else
aside from hostname. I have /etc/init.d in my target directory being
populated with relevant scripts S02abc, S90xyz, S91abcxyz, S92zyx. I
operate under the belief that init.d contents get executed in order of
their numbers after S, and that the names after S<num><name> do not
matter. In addtion, we are appropriately setting the permissions, which
I've verified in both the /etc/init.d of the subject on startup and with
our install command on the buildroot package that we have.

But what I'm seeing is something that appears to be spurious results that
are inconsistent across runs. One host will execute a script like what is
below just fine on startup, and sometime another system will not, despite
the fact that the files are identical in the init.d directory for each
host.

S90createSymlinkTree:
#!/bin/sh
mkdir -p /tmp/xyz/abc
ln -s /tmp/some_target /tmp/some_link

If the script above doesn't run, then /tmp will not be populated, and the
other scripts will fail. If we run it manually it always works, but it has
to work on startup.

Lastly, in addition to having an S90 script that does the above, we have a
S91 script that may create as many as three instances of a process as a
daemon based on the hostname. We also have evidence that the three
invocations are each hit by the script on init for this particular file,
and if one is running, it is only the last that was invoked by the startup
script. That script is different, however, and it looks like this:

#!/bin/sh
#...
do_start()
{
if [ "$(hostname)" = "dev-mon-0" ]
then
cd /tmp/dir1/dir1 && start-stop-daemon -b --start --quiet --pidfile
${PIDFILE}1 --make-pidfile --exec ${DAEMON} -- \
  $DAEMON_ARGS ;
                sleep 2;
cd /tmp/dir1/dir2 && start-stop-daemon -b --start --quiet --pidfile
${PIDFILE}2 --make-pidfile --exec ${DAEMON} -- \
  $DAEMON_ARGS ;
                sleep 2;
cd /tmp/dir1/dir2 && start-stop-daemon -b --start --quiet --pidfile
${PIDFILE}3 --make-pidfile --exec ${DAEMON} -- \
  $DAEMON_ARGS ;
fi

if [ "$(hostname)" = "dev-filter-1" ]
then
cd /tmp/dir2 && start-stop-daemon -b --start --quiet --pidfile $PIDFILE
--exec $DAEMON -- \
  $DAEMON_ARGS \
  || return 2 ;
fi

if [ "$(hostname)" = "dev-low-3" ]
then
cd /tmp/dir3 && start-stop-daemon -b --start --quiet --pidfile $PIDFILE
--exec $DAEMON -- \
  $DAEMON_ARGS \
  || return 2 ;
fi

if [ "$(hostname)" = "dev-hi-2" ]
then
cd /tmp/dir4 && start-stop-daemon -b --start --pidfile $PIDFILE --exec
$DAEMON -- \
  $DAEMON_ARGS \
  || return 2 ;
fi
}

At other times, the symlink tree will appear in /tmp, but the process won't
be there in a host that is only supposed to have one, and the evidence that
the daemon tool ever tried to run it is also not there. In which case, we
check the hostname of the system to ensure that the script ran matched it
on the if statement. But it matches, and so we conclude that the script
never ran. But for any box, if we run them from the shell manually and in
the order we specified in the numbers, it *always* works.

What is going on?? All I want to do is have etc/init.d work as documented
on startup!!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160307/c239c1e4/attachment.html>

[Buildroot] buggy init script

[Steve Calfee]

On Mon, Mar 7, 2016 at 6:48 AM, Kenneth Adam Miller
Hi Ken,

This is not so much a buildroot question as a linux user question.
Anyway a couple of maybe helpful answers below.

<kennethadammiller@gmail.com> wrote:
> I have a buildroot system with multiple target bzImages, each with a
> respective configuration. The configurations don't differ in much else aside
> from hostname. I have /etc/init.d in my target directory being populated
> with relevant scripts S02abc, S90xyz, S91abcxyz, S92zyx. I operate under the
> belief that init.d contents get executed in order of their numbers after S,
> and that the names after S<num><name> do not matter. In addtion, we are
> appropriately setting the permissions, which I've verified in both the
> /etc/init.d of the subject on startup and with our install command on the
> buildroot package that we have.
>

This assumption is correct.

> But what I'm seeing is something that appears to be spurious results that
> are inconsistent across runs. One host will execute a script like what is
> below just fine on startup, and sometime another system will not, despite
> the fact that the files are identical in the init.d directory for each host.
>

You don't give enough info on your environment. What is the rootfs
built into on your test runs? NFS? Flash? etc. How did it get there?

If you always do a make clean, fresh install for each flavor of init
scripts, do you have these problems?

What I am getting at is if you always just untar the rootfs into say a
nfs partition, the old stuff will be there. So now you have parts of
two filesystems and probably your run stuff will be confusing (new
files will over-written but old files will still be there). Check
/etc/init.d after boot and look for litter. dmesg and
/var/log/messages might have useful info.

Lots of packages add init scripts. Add your customizations one at a
time, and try to find the source of your problems. If you are nfs
booting you can alter the /etc/init.d scripts easily and reboot to
test again.

Good Luck, Steve

[Buildroot] buggy init script

[Arnout Vandecappelle]

On 03/07/16 15:48, Kenneth Adam Miller wrote:
> I have /etc/init.d in my target directory being populated with relevant scripts
> S02abc, S90xyz, S91abcxyz, S92zyx. I operate under the belief that init.d
> contents get executed in order of their numbers after S, and that the names
> after S<num><name> do not matter.

  The scripts are actually run by /etc/init.d/rcS, so you can check there how it 
is done. Basically it will execute everything that starts with S in shell sort 
order.


  To debug things, the easiest thing to do is to change the shebang into
#! /bin/sh -x
which will print each command on the console before it is executed. Of course, 
that's assuming you have a console, otherwise things are more difficult to debug...


  Regards,
  Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF