[06:14:04]  ***  hadess
   (n=hadess@cpc1-glfd5-2-0-cust794.6-2.cable.virginmedia.com) has joined
   chat #udev.
   [06:14:27]  <hadess> kay_: got a sec?
   [06:16:33]  <hadess> i'm trying to delay an event helper getting run:
   http://pastebin.com/m54319fa2
   [06:20:22]  <hadess> kay_: or find another way to find whether bluetooth
   devices are available
   [07:31:19]  <kay_^ hey! i'm back
   [07:34:30]  ***  kay_ is now known as kay.
   [08:45:56]  <hadess> kay: hey!
   [08:46:09]  <kay^ hey!
   [08:46:19]  <hadess^ so, i have a little problem with my "on-demand"
   bluetooth start up scripts
   [08:46:44]  <hadess> udev will emit an event when starting up, when root
   fs is still read only
   [08:48:02]  <kay^ you do coldplug after the rootfs in writable, and get
   all events again, right?
   [08:48:23]  <hadess^ that's what i'd want, yes
   [08:48:37]  <kay^ you are sure, that it isn;t that way?
   [08:49:03]  <hadess^ notting mentioned to me that it could be a problem, i
   haven't actually tested
   [08:49:06]  <kay^ i mean, you don't have /usr on differnt partition,
   right?
   [08:49:21]  <hadess> me, no
   [08:49:25]  <hadess> but people might
   [08:49:41]  <kay> yeah, they are on their own then :)
   [08:49:57]  <kay> all stuff will break in interesting ways :)
   [08:50:37]  <kay> but with all tools on the rootfs, the coldplug thing
   should be fine, i think
   [08:50:39]  <hadess> is there a good way for me to check whether / would
   be ro, and defer?
   [08:51:21]  <kay> you currently see the ro /, when called?
   [08:51:40]  <kay> and you are not called again later?
   [08:51:44]  <hadess> as i mentioned, didn't test, just notting's word for
   it
   [08:51:57]  <hadess> maybe i should just try that...
   [08:52:01]  <kay> ah, i see. i guess you need to try :)
   [08:52:24]  <kay> coldplug should happen after the rootfs is writable
   [08:52:39]  ***  kzak has left chat #udev (Read error: 113 (No route to
   host)).
   [08:52:53]  <kay> the only problem is if you have parts of the filesystem
   on different disks which are not available that time
   [08:53:14]  <hadess> yeah, things will break
   [08:53:16]  <kay> then you could, if you detect this, return non-zero from
   the RUN+="..." rule
   [08:53:36]  <kay> and you will be called again after all local fss are
   mounted
   [08:53:36]  <hadess> what happens if i return non-0?
   [08:53:45]  <hadess> oh, excellent
   [08:53:54]  <kay> then the device is marked as failed
   [08:54:05]  <kay> and a later boot script calls all failed events again
   [08:54:14]  <kay> than *might* work
   [08:54:52]  <kay> not sure if anybody ever relied on that, it's there, but
   it might just have problems nobody ever cared about
   [08:55:05]  ***  kzak (n=kzak@176.21.broadband11.iol.cz) has joined chat
   #udev.
   [09:17:29]  <hadess> kay: stupid question, what what can i use to check
   whether a path is on a read-only partition/device?
   [09:18:29]  <kay^ i guess, you have to open something for writing
   [09:18:37]  <hadess> huh
   [09:18:49]  <kay^ or read the sysfs ro attribute for the underlying device
   [09:19:15]  <hadess> i think i'll just grep the output of mount for now :)
   [09:19:21]  <kay^ what goes wrong, if / is ro? what does it want to write?
   [09:19:49]  <hadess^ well, we emit an upstart signal
   [09:19:57]  <hadess> and upstart wouldn't be able to start bluetoothd
   [09:20:00]  <kay> you are not adding stuff like this to an event handler,
   right?
   [09:20:27]  <hadess> i am, shouldn't i be?
   [09:20:33]  <kay> i mean you are not calling the mount binary here?
   [09:20:52]  <kay> no, you shouldn't, definitely not
   [09:22:09]  <hadess^ this is the udev helper: #!/bin/sh
   [09:22:09]  <hadess> # Run "initctl log-priority info" to get debug from
   [09:22:09]  <hadess> # upstart about events being processed, or pass
   [09:22:09]  <hadess> # --debug to your kernel arguments
   [09:22:09]  <hadess> emit_event()
   [09:22:10]  <hadess> {
   [09:22:11]  <kay> Keybuk: isn't that to be solved in upstart?
   [09:22:12]  <hadess>         /sbin/initctl emit --no-wait $1
   [09:22:16]  <hadess> }
   [09:22:18]  <hadess> # If any of those paths are read-only, bail
   [09:22:20]  <hadess> if `mount | grep "on / type" | grep -q ro` ; then
   [09:22:22]  <hadess>         return 1;
   [09:22:24]  <hadess> fi
   [09:22:26]  <hadess> # If the action is add, we always have an adapter
   [09:22:28]  <hadess> if test "x$ACTION" = "xadd" ; then
   [09:22:30]  <hadess>         emit_event fedora.bluetooth-adapter-available
   [09:22:32]  <hadess>         exit 0
   [09:22:34]  <hadess> fi
   [09:22:36]  <hadess> # Check whether any devices are available
   [09:22:38]  <hadess> if `udevadm info --export-db | grep -q -e
   '/devices/.*/bluetooth/.*'` ; then
   [09:22:40]  <hadess>         emit_event fedora.bluetooth-adapter-available
   [09:22:42]  <hadess> else
   [09:22:46]  <hadess>         emit_event
   fedora.bluetooth-adapter-not-available
   [09:22:48]  <hadess> fi
   [09:22:49]  <kay> oh, stop it please :)
   [09:22:50]  <hadess> exit 0
   [09:22:52]  <hadess> crap
   [09:22:54]  <hadess> sorry!
   [09:22:55]  <kay> i'm puking :)
   [09:22:56]  <hadess> http://pastebin.com/m58bce486
   [09:23:28]  <kay> no, it's fine to paste here, but what is crap like:
   udevadm info --export-db
   [09:23:40]  <kay> it's insane
   [09:24:24]  <kay> i guess someone needs to find a sane way to do that,
   that looks like an awful piece of total crap :)
   [09:25:02]  <hadess> why thank you
   [09:25:17]  <kay> calling mount and dumping the udev database from an
   event, that's really wrong on so many levels :)
   [09:25:19]  <hadess> i work with what i have
   [09:25:33]  <kay> yeah, sorry, it; not personal
   [09:25:39]  <kay> it's not, i mean
   [09:25:52]  <hadess> get me better tools, and i won't be doing crazy shit
   [09:26:18]  <kay> so back to square one: what are you trying to
   accomplish?
   [09:26:47]  <hadess> start bluetoothd when a bluetooth adapter shows up,
   stop it when the last bluetooth adapter is removed
   [09:27:21]  <kay> bluetoothd watches its devices, right?
   [09:27:27]  <hadess> yes
   [09:27:39]  <kay> so you don't do refcounting in udev events
   [09:27:45]  <kay> and never stop anything
   [09:27:55]  <kay> let blutoothd exit if it has nothing to do
   [09:27:57]  <hadess> but we're trying not to run bluetoothd when there's
   no adapters
   [09:28:10]  <kay> yeah, but make it exit if it has no devices left
   [09:28:33]  <hadess> hmm
   [09:28:38]  <kay> so you get rid of the "refcounting" hack by dumping the
   db
   [09:29:18]  <hadess> i guess i could do that as a bluetoothd plugin
   [09:29:20]  <kay> and you make it exit immediately when its already
   running
   [09:30:00]  <kay> you start it with  every device event, and it will just
   exit,when its not needed because it runs already
   [09:30:16]  <hadess> it runs on dbus, so it would already do that
   [09:30:24]  <kay> sounds good
   [09:30:52]  <kay> same thing, if it can not run because / is ro, let it
   exit
   [09:31:03]  <hadess> i think it already does that
   [09:31:11]  <kay> and the next event will try to start it again
   [09:31:30]  <hadess> you mean that i could do that using only udev and no
   upstart?
   [09:31:55]  <kay> i don't think there needs to be anything of this in udev
   rules
   [09:32:02]  <kay> maybe, i can't say
   [09:32:18]  <Keybuk> what does bluetoothd do with the adapter?
   [09:32:19]  <hadess> any of "this" what?
   [09:32:29]  <kay> just trigger the start of the daemon from the event, and
   noting else
   [09:32:34]  <hadess> Keybuk: brings it up, and makes it available to
   user-space
   [09:32:42]  <Keybuk> does it need to even be running if an adapter is
   present but no application requires it?
   [09:32:47]  <Keybuk> if not, consider d-bus activation instead
   [09:32:50]  <hadess^ yes
   [09:33:11]  <hadess> and no, dbus activation was already tried, and it
   wouldn't work for us
   [09:35:24]  <kay^ you can dbu-activate it from the "new bt adapter" event,
   right?
   [09:35:25]  <hadess> should i run bluetoothd as a daemon from the RUN+=,
   or with --nodaemon?
   [09:35:49]  <kay^ it'need to detach from udev
   [09:35:55]  <kay> it needs ...
   [09:35:56]  <hadess^ doesn't really help, does it? whether i auto-start it
   with dbus, or just launch it
   [09:36:35]  <kay^ i can't tell, both should work fine, if you have no
   other startup paths, it does not matter, i guess
   [09:36:54]  <kay> you never have a client that wants to start it up,
   right?
   [09:37:06]  <hadess^ we shouldn't no
   [09:37:17]  <kay^ i mean the "new adapter" is the only way to bring up the
   service?
   [09:37:29]  <hadess^ it's the best way
   [09:37:46]  <hadess> applications should already handle the dbus service
   not being available
   [09:38:15]  <kay^ and you tell the running daemon, by calling the same
   binary about a new adaper?
   [09:38:21]  <hadess> and there's not really any difference between no
   devices and no dbus service
   [09:38:36]  <kay^ or does it listen for events itself?
   [09:38:47]  <hadess^ no, bluetoothd already monitors new devices coming in
   through netlink
   [09:39:26]  <kay> i see, so calling the binary again for the next adapter
   will just make it exit(0), right?
   [09:39:45]  <hadess> probably exit 1 as it's already running
   [09:40:24]  <kay> yeah, you just want to prevent the event to return a
   failure
   [09:41:11]  <hadess> i could do that in a helper
   [09:41:21]  <hadess> check whether it's already on the bus using dbus-send
   [09:41:38]  <kay> you want it to return 1 if it wasn't running, but / is
   ro, or something esle
   [09:42:23]  <kay> you could do, i guess, i would just add that to the
   binary itself
   [09:43:37]  <kay> so udev "add" events would just always call the helper
   or the daemon, regardless of the state, and the daemon would take care of
   exiting itself
   [09:43:45]  <hadess> yeah
   [09:43:58]  <kay> then noting of the magic will be needed, right?
   [09:45:37]  <kay> hey, and sorry for calling it piece of crap, i'm just
   buried in stuff like this, and can't manage it :)
   [09:46:15]  <hadess> i think some bits would have to live in the daemon,
   some others in the helper script
   [09:46:34]  <kay^ what would be in the helper?
   [09:47:29]  <kay> i think it should maybe go into the daemon itself,
   otherwise it could be racy and you need to cover the races in the daemon
   anyway
   [09:50:36]  <kay> what else than: ACTION="add",  RUN+="bluetoothd
   --exit-if-already-running" would be needed?
   [09:51:27]  <kay> it would return 0 if started successfully, or it was
   already running
   [09:52:01]  <kay> return 1 if it wasn't already running, and it was unable
   to start because of ro /, or any other failure
   [09:53:33]  <kay> and it exits if no adapter is left, by dropping the
   service, while still listening to events, and if no "new device" event
   comes in, it will exit
   [09:54:56]  <kay> if after dropping the service, a "new device" comes in
   it will try to reclaim the service, and exit if the new daemon has taken
   it over, otherwise it will keep running for the new device