Cirrus
At the core of BIG-IP is our configuration engine mcpd. It contains a notification service for daemons on the device to notify them when the state of it's configuration changes (ie. an object is added/deleted in the GUI).
I wrote eventd as another one of those listening daemons. Right now, the only way to configure eventd is by building a client with the iControl Management.EventSubscription interface (which you probably figured out). The client then configures "listeners" which contain what type of notifications it wants to hear about.
The eventd sits in a event loop listening for events. When one occurs, it looks in it's configuration (stored on disk under /config/eventd.xml) for listeners that want to be notified of that specific state change. It then pushes the change into a queue for each listener.
Listeners can be configured to buffer responses based on various criteria (see the EventSubscription's create method.
When the threshold for a notification occurs (max messages, timeslice, etc), it will attempt to make a connection to the EventNotification interface on your listener. If the connection attempt fails, it retries a couple of times (also configurable). After the retry limit fails, it will put the listener in a "disabled" state. The only way to bring this back up is to re-enable it with the EventSubscription methods. This is probably what's happening to you.
As for a SSL connection, I honestly haven't tested that. I'm not sure why it wouldn't work and I'm not sure if it's a client thing (in my daemon) or a server thing (on the perl side). Definitely something I'll have to test out when I can get to it.
As for the user field, that was originally included as a future placeholder if we ever got the username included down in the configuration daemon for changes. That was on the roadmap at the time but still hasn't been implemented so for now, the username will be empty.
If you want to debug eventd, you should do the following
1) bigstart shutdown eventd
2) $ /sbin/eventd -d -f
That will run eventd in the foreground printing debug statements.
Hopefully this helps clear some things up.
-Joe
