[rfc] move activation to a helper process

[Havoc Pennington]

David Zeuthen wrote:
> Hmm, ok, so this is actually a new requirement. E.g. for this to work we
> will require that service files are owned by root. 
> 
> This is fine with me but I can see this breaking some stuff, for example
> package management systems where you create a new user for every package
> (LFS recommends this or did once at least).
> 
> I don't know whether it's sane to check it's a system directory - it's a
> pretty loose term anyway, I suspect you mean something in /usr, /etc
> or /opt. Not sure we should hard code this into the sources. I can see
> this break things like jhbuild and garnome that builds it's own D-Bus
> (for better or worse!). So I think just checking whether it's owned by
> root is good enough.

What I meant by "system directory" is "one of the service file 
directories listed in system.conf" - in fact, maybe we don't need to 
check owned by root if you think that will cause problems - if you make 
the service file directory writable by users, I guess it's probably your 
own fault... maybe it's even useful in some scenarios to let certain 
groups write to one of these directories.

> We could also just commit all the code for 1.0, I mean it's a nice
> feature and if it doesn't work we should fix it soon :-)

I was deferring to John on this point - though I was thinking he was 
trying to make FC6, and it looks like we didn't make FC6, so there may 
be no hurry now other than embarrassment that reaching 1.0 is taking for 
frickin' ever.

It'd be nice to stick 1.0 in an FC6 update though, so maybe we should 
really try to stick to a freeze.

> (Btw, if would be nice if we used git for the core, then I'd just commit
> this to my repo and you could grab these bits for now.)

yeah, I don't understand git. I tried to use it to do some Cairo stuff 
and just found myself saying "this thing was obviously written by kernel 
developers"

> We don't need to lock when not build tests as we can assume that system
> malloc is MT-safe. It's only applicable for DBUS_BUILD_TESTS. Btw, I
> didn't bother making the bits for failing mallocs MT-safe, we probably
> should, but the right way to do this requires a DBusMutex to lock around
> the whole thing. I can do this if you want.

I don't think dbus_malloc in test mode needs to be MT-safe beyond 
whatever is required for the tests to work.

> Two other things I had to fix. In dbus/dbus-threads.c
> 
>> @@ -350,8 +350,6 @@ init_uninitialized_locks (void)
>>  {
>>    DBusList *link;
>>  
>> -  _dbus_assert (thread_init_generation == 0);
> 
> I'm pretty sure this is wrong as we call dbus_shutdown() between tests
> and docs for this one tells use to use dbus_thread_init() again. Is this
> fix right?

The assert should probably be "thread_init_generation != 
_dbus_current_generation" or something like that instead?

I think there was a patch at one point with several comparisons to 0 
that should have been to _dbus_current_generation instead and I had 
pointed it out in the patch review, so if you could grep for other cases 
of this bug that might be smart.

> which I also think is the right fix because we should expect OOM
> everywhere. Right?

Well, everywhere that can fail with OOM, but yeah, that includes 
anything that returns DBusError since the DBusError has to be malloc'd.

> Anyway, looks like we are getting there. Apart from the TODO's
> identified above I also need to handle the User= key's presence
> depending on whether we are a system bus or not. That shouldn't be hard
> though.

Thanks, will look at the patch again soon.

Havoc