Fedora Core 4 (FC4) will not shutdown properly
 

I've been plagued with random shutdown problems everytime there is a kernel update to SMP from fedora core.

I have a script running which shuts down the system nightly with "poweroff", if key programs are not running. It was working fine but now it does a full shutdown but the machine doesn't power off. Thus if it doesn't poweroff the auto start at 11:30 doesn't execute. It used to work.

I have "kernel /vmlinuz-2.6.14-1.1637_FC4smp ro root=LABEL=/ rhgb apci=force quiet" in grub.conf

The log files show a full shutdown:
Nov 28 02:00:27 siren rpc.statd[1800]: Caught signal 15, un-registering and exiting.
Nov 28 02:00:28 siren auditd[1814]: The audit daemon is exiting.
Nov 28 02:00:28 siren kernel: audit(1133161228.143:1142): audit_pid=0 old=1814 by auid=4294967295
Nov 28 02:00:28 siren kernel: Kernel logging (proc) stopped.
Nov 28 02:00:28 siren kernel: Kernel log daemon terminating.
Nov 28 02:00:29 siren exiting on signal 15


Anyone have any ideas where I can start looking to debug this problem?

There is a process named "siren", which is causing troubles. Never heard of this process, daemon before.

Siren is the host name of the machine.

It looks like ACPI is not working correctly. This may vary by which kernel you are using. It is my understanding that ACPI is what is responsible for transitioning from the completely shut down state to the actual powered off state. I could be wrong about this. I would start there, though.

I did a manual shutdown and this came on before the power safe mode on the montor kicked in. What's it mean?

Badness in send_IPI_mask_bitmask at arch/i386/kernel/smp.c:168 (Tainted: P )
[<c01148cd>] send_IPI_mask_bitmask+0x78/0x7a
[<c0114c81>] smp_send_reschedule+0x1a/0x1b
[<c011d595>] __migrate_task+0xab/0xad
[<c011d629>] migration_thread+0x92/0x114
[<c011d597>] migration_thread+0x0/0x114
[<c0133d89>] kthread+0x93/0x97
[<c0133cf6>] kthread+0x0/0x97
[<c0101d5d>] kernel_thread_helper+0x5/0xb

In your grub.conf, you said you have

Shouldn't that be

I'm not sure; I don't use that particular boot option. As for that stack trace, I'm not sure exactly what's causing it. What kernel package are you using?

Now don't I feel dumb!!! That was the problem. I've been copying that line... I guess I got dyslexic in one of the cut and paste operations.

Thanks for all the help.

Not a problem at all. I'm glad we got it figured out.