i think this would be by design, you shouldn't be opening a connection to dbus without a timeout, and you shouldn't be waiting for a reply without timeout. how does dbus scripts handle this? if it doesn't take a parameter, you will need to use dbus directly for any unreliable work.
It first i thought it was just dbus-scripts session , but im also getting problems with --system.
The dbus-script stop listening and the last process it tried to execute becomes a zombie.
for example:
/opt/customs/scripts/endCall * * com.nokia.csd.Call CreateRequested *
# cat /opt/customs/scripts/endCall
1893 root 2088 D /bin/sh /opt/customs/scripts/endCall :1.19 null com.n
1901 root 0 Z [endCall]
endcall became a zombie....
any ideas ?