On 05/11/2015 07:34 PM, Sage Weil wrote:
> On Mon, 11 May 2015, John Spray wrote:
>> On 11/05/2015 17:29, Owen Synge wrote:
>>> Dear all,
>>>
>>> Many init systems are used in linux now. Some ceph code needs to know
>>> the init system. (I must admit I have not looked into Solaris, MacOS and
>>> BSD and probably should have)
>>>
>>> It would be nice to have one function that detects the init system
>>>
>>> Since the init system can be specified in ceph and ceph-deploy
>>> explicitly it seems to be its reasonable to fail clearly to detect init
>>> system.
>>
>> I think I'm missing some background here. I was under the impression that
>> distros generally had a preferred init system (even if they let you switch),
>> and if another is in use then compatibility links are usually provided (e.g.
>> sysv-style calling through to systemd or vice versa). Given that, the distro
>> packaging then uses whatever the "right" way to start a service is for that
>> distro, and it's up to the distro to make sure that command is available.
>>
>> Otherwise don't we descend into a kind of madness where a package post-install
>> script can't start a service, because it doesn't know what command to run?
>
> Ceph daemons are marked with a file like
> /var/lib/ceph/$type/.../{upstart,systemd,sysvinit} indicating which init
> system is responsible for starting/stopping them. This is necesary mainly
> because on most systems they *do* coexist--at least with sysvinit scripts.
>
> Owen, this is basically what ceph-detect-init is doing now, right?
ceph-detect-init detects the init system and is intended to be used for
marking the init system. Once marked the init system will not need to be
detected a second time.
> IIRC the users are:
>
> - ceph-disk, when creating a new osd
> - ceph-deploy, when deploying a mon or mds or rgw
Yes though maybe it will be used by other services such as mon and mds
if needed in the future.
Best regards
Owen
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
