[Pkg-utopia-maintainers] Bug#672358: dbus: some machines do not shutdown properly and do not do poweroff

[Simon McVittie]

(Please reply to the bug, not to me - if you just reply to me, other
maintainers can't see your reply. Quoting full-text here for the benefit
of other maintainers.)

On 10/05/12 14:22, Jürgen Kaiser wrote:
> Am Donnerstag, 10. Mai 2012, 13:48:05 schrieben Sie:
>> As far as I understand it, what dbus does (no explicit stop directives)
>> is meant to work [...]
> 
> For run level 1 by my personal opinion dbus should be stopped, because I see 
> this run level as pour maintance mode and I need no dbus services in this 
> mode, may be I am wrong here, but this question has a more philosophic nature.

/etc/init.d/killprocs is run in runlevel 1, and should kill dbus, as far
as I can see; so we shouldn't need to run the script.

>> This might mean that something has changed in dbus and/or init more
>> recently, such that the way init kills it no longer works? (The same
>> dbus version worked fine last time I rebooted my laptop, though.)
>
> May be their is a change but that is beyond my time to check. I would also 
> think of changing in basic kernel features called by halt. My squeeze on the 
> notebook I talking about runs until this mature update with kernel 2.6.38.
> 
>> Alternatively: what upgrade path did you use on the machine where init
>> stalls waiting for dbus?
>
> I have made bad experience with simple updating a debian system from an old to 
> new version. So generally I do a complete new install process.

OK, so you're essentially using a new installation on both machines, and
in particular, the /etc on both machines is from wheezy and has not been
upgraded from squeeze?

> -Update from squeeze to wheezy has been done by clearly fresh installation on 
> a fresh partition with debootstrap, partition cleaned before with mkfs.ext4. 
> then manually added packages as I need. 
> - Preparation has been done on desktop system and than, after system is 
> working correct, this installation has been copied using rsync excluding 
> nonstatic dirs like sys, proc, tmp, etc to the notebook and notebook specific 
> changes are added.
> 
> For Information: I have a lot of machines to care for, so I handle it over 
> years in this way:
> - trying to have similar hardware (if possible) in processor type and graphic 
> cards to minimalize special configurations
> - setup debian version on a single machine prepare it
> - copy this installation to all other machines and make miniaml modifications 
> like hostname, fstab, etc
> - from this point on all machines run aptitude dist-upgrade periodically 
> avoiding mixing of debian versions
> 
>> Similarly, did you say you had a similar machine where init *does* kill
>> dbus properly without any intervention from you? If you do, what version
>> of Debian did you originally install on that machine, and what upgrade
>> path did you use there?
> See last remark for debian installation.
> 
> The desktop system on which I have prepared the system do a shutdown.
> The notebook system on which prepared system is copied to from desktop system 
> do not shutdown without stopping explicitely dbus.

Right, so either the problem is related to one of the changes you made
for the notebook, or it's hardware-specific.

> One remark about my expirience with linux on notebooks: The acpi bios is very 
> often buggy, there is no help from manufactorer and we (running linux) have to 
> live with this situation or do hard work in reenginiering. As I see kernel 
> devoloper do here a hard work and fix a lot. Maybe the whole thing is a bios 
> bug on my notebook invoked by dbus???
>  
>> I'd be interested to hear what happens with the packaged Debian kernel
>> (linux-image-3.2.0-2-amd64 from unstable and/or
>> linux-image-3.3.0-trunk-amd64 from experimental), if those can boot on
>> your hardware.
> Sorry but I have spend now some days with get the notebook run with wheezy. I 
> have not enough time to test some other debian kernels. I have send my bug 
> report hoping I could help a little bit to people having similar problems.
> 
> I see people on Ubuntu 12.04 have problems shutting down notebooks, then add 
> INIT_HALT=POWEROFF to /etc/default/halt and after this modification they have 
> success. It tried it and shutdown process succeded. But I think that this 
> solution is not the right way, because halt then do not a poweroff so 
> different hardware could be enabled after shutdown which is not a good 
> solution if a notebook runs on battery.

What is in /etc/default/halt on each of your machines?

Are you absolutely sure that adding/removing stop symlinks for dbus, and
not changing anything else, made the notebook power off / not power off?
Might you have changed something else at the same time, like
/etc/default/halt or the difference between shutdown -h and shutdown -hP?

(I wouldn't be surprised if halt vs. poweroff matters on certain
notebook hardware, but that shouldn't be anything to do with
dbus-daemon, which is fundamentally just a message-passing daemon with a
Unix socket - it doesn't do anything to hardware-related itself.)

    S