On 13 Dec 2009, at 15:04, Jürgen Keil wrote:
>> All that's in system-hal:default.log is:
>>
>> [ Dec 13 11:03:52 Executing start method ("/lib/svc/method/svc-hal start"). ]
>> hal failed to start: error 2
>> [ Dec 13 11:09:11 Method "start" exited with status 95. ]
>
> Hmm, there is a 250 second timeout in hald, function
> parent_wait_for_child(); hald should exit with exit code 2
> when hald's subprocesses don't start up in a timely manner.
>
> Not sure why you get a failure after ~ 320 seconds...
I thought the large time difference was interesting too.
>> An "svcadm clear hal" seems to fix things, but it
>> obviously shouldn't be failing in the first place.
>
> What kind of hot pluggable / removable media devices
> are connected to this system?
>
> USB? Firewire? Flash memory sticks? Flash memory reader?
> HDD? Optical devices?
>
> Is there a PS/2 floppy device configured / connected to
> this system?
This is a VM running inside VMware Fusion. The only devices accessible to the
VM were audio and an emulated serial port (used for capturing printer output, I
think), and an emulated e1000g using DHCP.
The host wasn't logging anything odd around this time. The guest logged one
error and a warning during the 320 seconds:
11:09:02 in.ndpd[470]: [ID 801587 daemon.error] fork: Resource temporarily
unavailable
11:09:03 svc.startd[9]: [ID 122153 daemon.warning]
svc:/network/routing/ndp:default: Method or service exist timed out. Killing
contract 65
11:09:05 last message repeated 1 time
11:09:10 svc.startd[9]: [ID 632263 daemon.warning]
svc:/network/routing/ndp:default: Method "/lib/svc/method/svc-ndp" failed due
to signal KILL.
Then the failure of svc-hal is logged. The errors re: fork and ndp has been
present in all 12x builds, perhaps earlier ones. It seems odd for memory to be
an issue when slightly later on X and GNOME is able to start up.
Cheers,
Chris
_______________________________________________
indiana-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
