[Pulp-list] Fedora 16, MongoDB and running from a source checkout

[Jeff Ortel]

On 11/11/2011 08:04 AM, Jay Dobies wrote:
> On 11/11/2011 02:02 AM, Nick Coghlan wrote:
>> I just upgraded my dev machine to F16 today and started getting the
>> following error:
>>
>> $sudo service pulp-server start
>> /etc/init.d/pulp-server: line 41: /etc/rc.d/init.d/mongod: No such file
>> or directory
>>
>> It seems that the default version of MongoDB in F16 has switched over to
>> using Upstart, so their init.d scripts are now missing.
>>
>> Replacing each occurrence of "/etc/rc.d/init.d/mongod" with "service
>> mongod" got things working again for me, but would such a change work on
>> all the platforms that Pulp supports?
>>
>> Cheers,
>> Nick.
>
> Ah bugger. We've had on our radar to figure out a systemd solution. Looks like this is
> going to kick us into doing something.

Actually, I've already addressed this.  Adding: SYSTEMCTL_SKIP_REDIRECT to our init.d 
scripts prevents redirection to systemd.  So, I think we're good for as long as init.d 
scripts (and /sbin/service) continue to be supported which I suspect will be for a good 
while longer.

bz: https://bugzilla.redhat.com/show_bug.cgi?id=735091

>
> I'm still liking the idea of a pulp-server script. That can take care of ensuring the
> proper services are running. That also gives us a place to hang our "init" operation off
> of since systemd won't support it.
>
> I'd like to have this script be the one to run pulp-migrate too. Not saying to remove
> pulp-migrate, but to have this script be the one stop for all of the user's needs.
>
> So supporting flags like:
> * start
> * stop
> * init
> * migrate (upgrade?)
> * dump (bad choice of words; basically tar and gzip all of the relevant logs we'd want
> them to send us in a support case, how freakin cool would it be to have this in the script?)
>
> Then we have a simple systemd script that calls into start and stop.

This /might/ work.  After review of systemd units, I have some reservations.  As I've 
mentioned before, the unit definitions make a strong assumption that what's being started 
is truely a daemon.  Worth a try though.  I'm really hoping that systemd will have (or 
add) 1st class support for service aggregation like we're doing here but I'm not holding 
my breath.

>
>