Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#30373 - [bluez] bluetooth init script kills ALL processes on stop action.

Attached to Project: Arch Linux
Opened by Natrio (natrio) - Wednesday, 20 June 2012, 07:37 GMT
Last edited by Tom Gundersen (tomegun) - Saturday, 23 June 2012, 00:45 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Tom Gundersen (tomegun)
Architecture All
Severity Critical
Priority Flash
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

After psmisc-22.18-1 package update, killall command without any parameters kills REALLY all.
See https://bugs.archlinux.org/task/30372

In bluetooth init scripts:
$ grep killall /etc/rc.d/bluetooth
killall $PAND_NAME >/dev/null 2>&1
killall $DUND_NAME >/dev/null 2>&1
killall $HIDD_NAME >/dev/null 2>&1
killall $SDPD_NAME >/dev/null 2>&1
killall $DAEMON_NAME >/dev/null 2>&1

If any of these variables will be empty, overkill will happen.
This task depends upon

Closed by  Tom Gundersen (tomegun)
Saturday, 23 June 2012, 00:45 GMT
Reason for closing:  Fixed
Comment by Thomas Bächler (brain0) - Wednesday, 20 June 2012, 08:48 GMT
Overkill meaning "No more processes in this runlevel" during reboot or shutdown - although it is a bug in psmisc, the bluetooth rc.d script is still broken, as SDPD_NAME and SDPD_EXEC are not set, but used.
Comment by Natrio (natrio) - Wednesday, 20 June 2012, 08:52 GMT
>> Overkill meaning "No more processes in this runlevel" during reboot or shutdown
Yes, but if yoy run the command
/etc/rc.d/bluetooth stop
it meaning like "kill all system immediate" :)
Comment by Eric Belanger (Snowman) - Wednesday, 20 June 2012, 09:20 GMT
FTR: the bug in psmisc is fixed in psmisc-22.18-2
Comment by Tom Gundersen (tomegun) - Wednesday, 20 June 2012, 10:02 GMT
Natrio: Thanks for the report. Eric: thanks for fixing it.

I took this opportunity to tidy up the rc script a bit. However, I suspect the whole thing could and should be rewritten. E.g. I notice that the systemd unit file shipped upstream only starts the main daemon and not any of the auxiliary ones. Could it be that we don't need to start them either (i.e. they are started on demand by the main daemon?). I'd need to look into this, but if anyone happens to know I'd be interested...
Comment by Thomas Bächler (brain0) - Wednesday, 20 June 2012, 11:03 GMT
First of all, some daemons have been replaced by plugins to bluetoothd - in the past, you needed hidd, then it was a plugin, now it's built-in (no idea why hidd still exists, as it is never used).

Second, you can configure some of this using the main daemon. I don't think you can configure dund and pand automatically, but I don't really know. You may still need rfcomm - while you can configure serial ports for a connected device, rfcomm setup is needed if you want to connect to a bluetooth device on demand when accessing the serial port.

Loading...