initctl unable to communicate with init

[Chris Packham]

On Mon, May 3, 2010 at 1:02 PM, Chris Packham <judge.packham at gmail.com> wrote:
> On Mon, May 3, 2010 at 12:48 PM, Kees Jongenburger
> <kees.jongenburger at gmail.com> wrote:
>> Hello Chris,
>>
>> On Mon, May 3, 2010 at 6:57 PM, Chris Packham <judge.packham at gmail.com> wrote:
>>> Hi,
>>>
>>> We've been using upstart in our embedded products for some time now
>>> (we're using upstart 0.5.1). I'm in the process of porting our
>>> software to a new hardware platform and I'm running into a problem
>>> thats got me stumped.
>>>
>>> Our first init script mounts the file systems and then uses "initctl
>>> reload" to reload the upstart config from the on-flash upstart config.
>>> The problem is that "initctl reload" just hangs waiting forever. As
>>> far as I've been able to debug so far it seems to be in the dbus
>>> message dispatch which should have sent the message to init. I think
>>> its waiting for a response it never sees, I also think init never got
>>> the message.
>>
>> Are you using a initramfs? who mounts the required file system for
>> upstart to work?
>
> It is an initramfs (squashfs) mounted by the kernel/bootloader.
>
>> try replacing upstart by a shell script and once you have a shell
>> exec /sbin/init with extra debugging.
>
> I'm already running with #define DEBUG in init/main.c and init=/bin/sh
> so I can start init after getting a shell. I might just add -DDEBUG to
> configure and see what else I get.

The same problem seems to affect the debug event that gets sent when
we build with -DDEBUG. After that event gets sent nothing happens, I
think its the same problem just happening earlier.

>> Double check your kernel configuration to have networking and sockets enabled.
>>
>
> grep -e 'CONFIG_\(NET\|INET\|UNIX\)=' .config
> CONFIG_NET=y
> CONFIG_UNIX=y
> CONFIG_INET=y
>
>>> I've run the same code on one of our existing platforms and that
>>> starts up normally so I'm thinking its a toolchain/kenrel setup issue
>>> but the only differences I can see in that area are the things that
>>> _are_ different.
>>
>> Your hardware might also be different causing a different events to happen
>> in a different order (for example a tmpfs to be mounted over the place
>> where upstart has it's unix socket waiting).
>>
>
> Hmm hadn't thought of that. One of the first things the script does is
> mount tmpfs, procfs and sysfs. I might take that out and do it
> manually as an experiment.
>

Mounting manually first (and disabling re-mounting) doesn't seem to
have any effect on this problem.

One hardware difference I haven't worked through yet is that there is
no driver for the real time clock on the board I have (or at least I
haven't found and configured the right one). I've been putting off
that work as an easy task I can do later. Are there any system calls
used that require a working rtc? I didn't think there were any such
calls.