autodetecting init system.

autodetecting init system.

[Owen Synge]

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 see 4 ways I can see to detect init system.

(A) Check pid 1.
(B) Use a database of OS to init mapping / compile time.
(C) look for init manipulation tools and infure the init system from tools.

Comments:
~~~~~~~~

(A1) systmd can be detected easily with.

 grep -qs systemd /proc/1/comm

(A2) With init scripts such as its hard to know what the init system.

(B1) For operating systems like RHEL, SLE, CENTOS, Fedora and scientific
linux this works well.

(B2) FOr operating systems like newer debian and ubuntu releases more
than one init system can be installed and used on the OS, so making a
database / doing it at compile time are not practical on all OS's

(C1) This is fairly reliable.

(C2) sysV tools have compatibility scripts / programs on other platforms
so if you use a points system for each init system helper script you can
infure systemd over sysV if sytemctrl exists for example.

So to summarise this:
~~~~~~~~~~~~~~~~~~~~

(1) No one system is perfect in all cases.
(2) Combined these systesm can provide reliable init system detection.

My proposed approach.
~~~~~~~~~~~~~~~~~~~~

(I) Use all three approaches where each approach can provide and answer,
or fail to provide an answer.

(II) Should any approaches disagree -> fail to detect init system.

(III) Should all approaches agree -> then return init system.

(III) Should no approaches provide an init system -> fail to return init
system.

Comments
~~~~~~~~

This multi layered and comparing way of doing init systems may seem
complete overkill, or maybe its useful.

What do you guys think?

Best regards

Owen

Re: autodetecting init system.

[John Spray]

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?

Cheers,
John

Re: autodetecting init system.

[Owen Synge]

On 05/11/2015 06:37 PM, 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.

I am not sure that sysV can emulate systemd, but systemd can and does
emulate sysV by default on SUSE and I think also debian .

> 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?

I have not yet tested converting ubuntu or debian latest releases with
non standard init systems (anything other than systemd).

The main reason is I do expect the exact "madness" you predict, that
said they claim support for this.

best regards

Owen

Re: autodetecting init system.

[Sage Weil]

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?

IIRC the users are:

 - ceph-disk, when creating a new osd
 - ceph-deploy, when deploying a mon or mds or rgw

Thanks!
sage

Re: autodetecting init system.

[Owen Synge]

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

Re: autodetecting init system.

[Owen Synge]

On 05/11/2015 06:29 PM, 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 see 4 ways I can see to detect init system.
> 
> (A) Check pid 1.
> (B) Use a database of OS to init mapping / compile time.
> (C) look for init manipulation tools and infure the init system from tools.
> 
> Comments:
> ~~~~~~~~
> 
> (A1) systmd can be detected easily with.
> 
>  grep -qs systemd /proc/1/comm


A further comment is how will this work in chroot / containers?

> 
> (A2) With init scripts such as its hard to know what the init system.
> 
> (B1) For operating systems like RHEL, SLE, CENTOS, Fedora and scientific
> linux this works well.
> 
> (B2) FOr operating systems like newer debian and ubuntu releases more
> than one init system can be installed and used on the OS, so making a
> database / doing it at compile time are not practical on all OS's
> 
> (C1) This is fairly reliable.
> 
> (C2) sysV tools have compatibility scripts / programs on other platforms
> so if you use a points system for each init system helper script you can
> infure systemd over sysV if sytemctrl exists for example.
> 
> So to summarise this:
> ~~~~~~~~~~~~~~~~~~~~
> 
> (1) No one system is perfect in all cases.
> (2) Combined these systesm can provide reliable init system detection.
> 
> My proposed approach.
> ~~~~~~~~~~~~~~~~~~~~
> 
> (I) Use all three approaches where each approach can provide and answer,
> or fail to provide an answer.
> 
> (II) Should any approaches disagree -> fail to detect init system.
> 
> (III) Should all approaches agree -> then return init system.
> 
> (III) Should no approaches provide an init system -> fail to return init
> system.
> 
> Comments
> ~~~~~~~~
> 
> This multi layered and comparing way of doing init systems may seem
> complete overkill, or maybe its useful.
> 
> What do you guys think?
> 
> Best regards
> 
> Owen
> 
> 
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB
21284 (AG
Nürnberg)

Maxfeldstraße 5

90409 Nürnberg

Germany
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: autodetecting init system.

[Loic Dachary]

[-- Attachment #1: Type: text/plain, Size: 2840 bytes --]

Hi Owen,

It would help to provide one or two use cases where (C) solves a problem that (B) (that is the current ceph-detect-init approach) does not solve. I sense there is something better in (C) but I can't think of a use case just now (maybe because I've been thinking about erasure code all day :-). 

Cheers

On 11/05/2015 18: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 see 4 ways I can see to detect init system.
> 
> (A) Check pid 1.
> (B) Use a database of OS to init mapping / compile time.
> (C) look for init manipulation tools and infure the init system from tools.
> 
> Comments:
> ~~~~~~~~
> 
> (A1) systmd can be detected easily with.
> 
>  grep -qs systemd /proc/1/comm
> 
> (A2) With init scripts such as its hard to know what the init system.
> 
> (B1) For operating systems like RHEL, SLE, CENTOS, Fedora and scientific
> linux this works well.
> 
> (B2) FOr operating systems like newer debian and ubuntu releases more
> than one init system can be installed and used on the OS, so making a
> database / doing it at compile time are not practical on all OS's
> 
> (C1) This is fairly reliable.
> 
> (C2) sysV tools have compatibility scripts / programs on other platforms
> so if you use a points system for each init system helper script you can
> infure systemd over sysV if sytemctrl exists for example.
> 
> So to summarise this:
> ~~~~~~~~~~~~~~~~~~~~
> 
> (1) No one system is perfect in all cases.
> (2) Combined these systesm can provide reliable init system detection.
> 
> My proposed approach.
> ~~~~~~~~~~~~~~~~~~~~
> 
> (I) Use all three approaches where each approach can provide and answer,
> or fail to provide an answer.
> 
> (II) Should any approaches disagree -> fail to detect init system.
> 
> (III) Should all approaches agree -> then return init system.
> 
> (III) Should no approaches provide an init system -> fail to return init
> system.
> 
> Comments
> ~~~~~~~~
> 
> This multi layered and comparing way of doing init systems may seem
> complete overkill, or maybe its useful.
> 
> What do you guys think?
> 
> Best regards
> 
> Owen
> 
> 
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Loïc Dachary, Artisan Logiciel Libre


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: autodetecting init system.

[Owen Synge]

On 05/11/2015 11:45 PM, Loic Dachary wrote:
> Hi Owen,
> 
> It would help to provide one or two use cases where (C) solves a problem 
> that (B) (that is the current ceph-detect-init approach) does not
> solve.

> I sense there is something better in (C) but I can't think of a use case 
> just now
> (maybe because I've been thinking about erasure code all day :-).

Hi Loic,

Please note that I believe we are correct to explicitly allow the user
to specify the init system and override any auto detection.

Hence I believe it is correct for autodetection to be able to fail.

Use case (1)
~~~~~~~~~~~~

When a new release of an operating system comes out with a different
init system (B) as a static database will not immediately account for
this solution.

For example

SUSE SLE 11 -> sysV
SUSE SLE 12 -> systemd
RHEL 5 -> sysV
RHEL 6 -> upstart
RHEL 7 -> systemd

When for example SLE12 came out ceph upstream code assumed ceph ran on
the sysV init system until appropriate patches where taken.

Since we can only test on "free as in beer" operating systems at this
moment covering these OS's with the database and appropriate tests is
problematic.

Use case (2)
~~~~~~~~~~~~

The use cases are on the latest debian, ubuntu platforms.

On both these platforms you can install alternative init systems.

on debian stable I can apt-get install the following init systems:

systemd
upstart
sysvinit

Hence assuming all debian stable systems are systemd (the default) is a
false assumption as (B) does not support users changing the init system
before installing ceph on debian and ubuntu as having a database of init
systems cannot support all platforms.

Use case (3)
~~~~~~~~~~~~

By supporting (B) and (C) and emitting a warning on operating systems
not in the database, populating the database will be quicker, and
correcting values in the database will be easier to verify.

In some ways, the code tests its self, at run time.

Summary:
~~~~~~~~
I think its a value decision, is the extra complexity of doing (B) and
(C) worth the corner case of supporting the people who chose to use non
default init system worth the code complexity. If we are supporting more
than one init detection mechanism, it may well be worth supporting all
of (A) (B) and (c).

Best regards

Owen



> Cheers
> 
> On 11/05/2015 18: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 see 4 ways I can see to detect init system.
>>
>> (A) Check pid 1.
>> (B) Use a database of OS to init mapping / compile time.
>> (C) look for init manipulation tools and infure the init system from tools.
>>
>> Comments:
>> ~~~~~~~~
>>
>> (A1) systmd can be detected easily with.
>>
>>  grep -qs systemd /proc/1/comm
>>
>> (A2) With init scripts such as its hard to know what the init system.
>>
>> (B1) For operating systems like RHEL, SLE, CENTOS, Fedora and scientific
>> linux this works well.
>>
>> (B2) FOr operating systems like newer debian and ubuntu releases more
>> than one init system can be installed and used on the OS, so making a
>> database / doing it at compile time are not practical on all OS's
>>
>> (C1) This is fairly reliable.
>>
>> (C2) sysV tools have compatibility scripts / programs on other platforms
>> so if you use a points system for each init system helper script you can
>> infure systemd over sysV if sytemctrl exists for example.
>>
>> So to summarise this:
>> ~~~~~~~~~~~~~~~~~~~~
>>
>> (1) No one system is perfect in all cases.
>> (2) Combined these systesm can provide reliable init system detection.
>>
>> My proposed approach.
>> ~~~~~~~~~~~~~~~~~~~~
>>
>> (I) Use all three approaches where each approach can provide and answer,
>> or fail to provide an answer.
>>
>> (II) Should any approaches disagree -> fail to detect init system.
>>
>> (III) Should all approaches agree -> then return init system.
>>
>> (III) Should no approaches provide an init system -> fail to return init
>> system.
>>
>> Comments
>> ~~~~~~~~
>>
>> This multi layered and comparing way of doing init systems may seem
>> complete overkill, or maybe its useful.
>>
>> What do you guys think?
>>
>> Best regards
>>
>> Owen
>>
>>
>>
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 

-- 
SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB
21284 (AG
Nürnberg)

Maxfeldstraße 5

90409 Nürnberg

Germany
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: autodetecting init system.

[Loic Dachary]

[-- Attachment #1: Type: text/plain, Size: 5305 bytes --]



On 12/05/2015 09:56, Owen Synge wrote:
> On 05/11/2015 11:45 PM, Loic Dachary wrote:
>> Hi Owen,
>>
>> It would help to provide one or two use cases where (C) solves a problem 
>> that (B) (that is the current ceph-detect-init approach) does not
>> solve.
> 
>> I sense there is something better in (C) but I can't think of a use case 
>> just now
>> (maybe because I've been thinking about erasure code all day :-).
> 
> Hi Loic,
> 
> Please note that I believe we are correct to explicitly allow the user
> to specify the init system and override any auto detection.
> 
> Hence I believe it is correct for autodetection to be able to fail.
> 
> Use case (1)
> ~~~~~~~~~~~~
> 
> When a new release of an operating system comes out with a different
> init system (B) as a static database will not immediately account for
> this solution.
> 
> For example
> 
> SUSE SLE 11 -> sysV
> SUSE SLE 12 -> systemd
> RHEL 5 -> sysV
> RHEL 6 -> upstart
> RHEL 7 -> systemd
> 
> When for example SLE12 came out ceph upstream code assumed ceph ran on
> the sysV init system until appropriate patches where taken.

So Ceph failed to run on SLE12 because it was relying on sysV ?

> 
> Since we can only test on "free as in beer" operating systems at this
> moment covering these OS's with the database and appropriate tests is
> problematic.
> 
> Use case (2)
> ~~~~~~~~~~~~
> 
> The use cases are on the latest debian, ubuntu platforms.
> 
> On both these platforms you can install alternative init systems.
> 
> on debian stable I can apt-get install the following init systems:
> 
> systemd
> upstart
> sysvinit
> 
> Hence assuming all debian stable systems are systemd (the default) is a
> false assumption as (B) does not support users changing the init system
> before installing ceph on debian and ubuntu as having a database of init
> systems cannot support all platforms.
> 
> Use case (3)
> ~~~~~~~~~~~~
> 
> By supporting (B) and (C) and emitting a warning on operating systems
> not in the database, populating the database will be quicker, and
> correcting values in the database will be easier to verify.
> 
> In some ways, the code tests its self, at run time.
> 
> Summary:
> ~~~~~~~~
> I think its a value decision, is the extra complexity of doing (B) and
> (C) worth the corner case of supporting the people who chose to use non
> default init system worth the code complexity. If we are supporting more
> than one init detection mechanism, it may well be worth supporting all
> of (A) (B) and (c).
> 
> Best regards
> 
> Owen
> 
> 
> 
>> Cheers
>>
>> On 11/05/2015 18: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 see 4 ways I can see to detect init system.
>>>
>>> (A) Check pid 1.
>>> (B) Use a database of OS to init mapping / compile time.
>>> (C) look for init manipulation tools and infure the init system from tools.
>>>
>>> Comments:
>>> ~~~~~~~~
>>>
>>> (A1) systmd can be detected easily with.
>>>
>>>  grep -qs systemd /proc/1/comm
>>>
>>> (A2) With init scripts such as its hard to know what the init system.
>>>
>>> (B1) For operating systems like RHEL, SLE, CENTOS, Fedora and scientific
>>> linux this works well.
>>>
>>> (B2) FOr operating systems like newer debian and ubuntu releases more
>>> than one init system can be installed and used on the OS, so making a
>>> database / doing it at compile time are not practical on all OS's
>>>
>>> (C1) This is fairly reliable.
>>>
>>> (C2) sysV tools have compatibility scripts / programs on other platforms
>>> so if you use a points system for each init system helper script you can
>>> infure systemd over sysV if sytemctrl exists for example.
>>>
>>> So to summarise this:
>>> ~~~~~~~~~~~~~~~~~~~~
>>>
>>> (1) No one system is perfect in all cases.
>>> (2) Combined these systesm can provide reliable init system detection.
>>>
>>> My proposed approach.
>>> ~~~~~~~~~~~~~~~~~~~~
>>>
>>> (I) Use all three approaches where each approach can provide and answer,
>>> or fail to provide an answer.
>>>
>>> (II) Should any approaches disagree -> fail to detect init system.
>>>
>>> (III) Should all approaches agree -> then return init system.
>>>
>>> (III) Should no approaches provide an init system -> fail to return init
>>> system.
>>>
>>> Comments
>>> ~~~~~~~~
>>>
>>> This multi layered and comparing way of doing init systems may seem
>>> complete overkill, or maybe its useful.
>>>
>>> What do you guys think?
>>>
>>> Best regards
>>>
>>> Owen
>>>
>>>
>>>
>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
> 

-- 
Loïc Dachary, Artisan Logiciel Libre


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: autodetecting init system.

[Owen Synge]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/12/2015 11:45 AM, Loic Dachary wrote:
> 
> 
> On 12/05/2015 09:56, Owen Synge wrote:
>> On 05/11/2015 11:45 PM, Loic Dachary wrote:
>>> Hi Owen,
>>>
>>> It would help to provide one or two use cases where (C) solves a problem 
>>> that (B) (that is the current ceph-detect-init approach) does not
>>> solve.
>>
>>> I sense there is something better in (C) but I can't think of a use case 
>>> just now
>>> (maybe because I've been thinking about erasure code all day :-).
>>
>> Hi Loic,
>>
>> Please note that I believe we are correct to explicitly allow the user
>> to specify the init system and override any auto detection.
>>
>> Hence I believe it is correct for autodetection to be able to fail.
>>
>> Use case (1)
>> ~~~~~~~~~~~~
>>
>> When a new release of an operating system comes out with a different
>> init system (B) as a static database will not immediately account for
>> this solution.
>>
>> For example
>>
>> SUSE SLE 11 -> sysV
>> SUSE SLE 12 -> systemd
>> RHEL 5 -> sysV
>> RHEL 6 -> upstart
>> RHEL 7 -> systemd
>>
>> When for example SLE12 came out ceph upstream code assumed ceph ran on
>> the sysV init system until appropriate patches where taken.
> 
> So Ceph failed to run on SLE12 because it was relying on sysV ?

When we first released on SLE12 yes, I haven't yet checked the latest
master.

Also if someone was "unusual" and used gentoo, mint, or other OS not in
a database known OS, they might get "unusual" results.

This is a use case example the use case is maybe beter stated:

Handling of Operating systems which are not in the database of known
operating systems.

Best regards

Owen



>>
>> Since we can only test on "free as in beer" operating systems at this
>> moment covering these OS's with the database and appropriate tests is
>> problematic.
>>
>> Use case (2)
>> ~~~~~~~~~~~~
>>
>> The use cases are on the latest debian, ubuntu platforms.
>>
>> On both these platforms you can install alternative init systems.
>>
>> on debian stable I can apt-get install the following init systems:
>>
>> systemd
>> upstart
>> sysvinit
>>
>> Hence assuming all debian stable systems are systemd (the default) is a
>> false assumption as (B) does not support users changing the init system
>> before installing ceph on debian and ubuntu as having a database of init
>> systems cannot support all platforms.
>>
>> Use case (3)
>> ~~~~~~~~~~~~
>>
>> By supporting (B) and (C) and emitting a warning on operating systems
>> not in the database, populating the database will be quicker, and
>> correcting values in the database will be easier to verify.
>>
>> In some ways, the code tests its self, at run time.
>>
>> Summary:
>> ~~~~~~~~
>> I think its a value decision, is the extra complexity of doing (B) and
>> (C) worth the corner case of supporting the people who chose to use non
>> default init system worth the code complexity. If we are supporting more
>> than one init detection mechanism, it may well be worth supporting all
>> of (A) (B) and (c).
>>
>> Best regards
>>
>> Owen
>>
>>
>>
>>> Cheers
>>>
>>> On 11/05/2015 18: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 see 4 ways I can see to detect init system.
>>>>
>>>> (A) Check pid 1.
>>>> (B) Use a database of OS to init mapping / compile time.
>>>> (C) look for init manipulation tools and infure the init system from tools.
>>>>
>>>> Comments:
>>>> ~~~~~~~~
>>>>
>>>> (A1) systmd can be detected easily with.
>>>>
>>>>  grep -qs systemd /proc/1/comm
>>>>
>>>> (A2) With init scripts such as its hard to know what the init system.
>>>>
>>>> (B1) For operating systems like RHEL, SLE, CENTOS, Fedora and scientific
>>>> linux this works well.
>>>>
>>>> (B2) FOr operating systems like newer debian and ubuntu releases more
>>>> than one init system can be installed and used on the OS, so making a
>>>> database / doing it at compile time are not practical on all OS's
>>>>
>>>> (C1) This is fairly reliable.
>>>>
>>>> (C2) sysV tools have compatibility scripts / programs on other platforms
>>>> so if you use a points system for each init system helper script you can
>>>> infure systemd over sysV if sytemctrl exists for example.
>>>>
>>>> So to summarise this:
>>>> ~~~~~~~~~~~~~~~~~~~~
>>>>
>>>> (1) No one system is perfect in all cases.
>>>> (2) Combined these systesm can provide reliable init system detection.
>>>>
>>>> My proposed approach.
>>>> ~~~~~~~~~~~~~~~~~~~~
>>>>
>>>> (I) Use all three approaches where each approach can provide and answer,
>>>> or fail to provide an answer.
>>>>
>>>> (II) Should any approaches disagree -> fail to detect init system.
>>>>
>>>> (III) Should all approaches agree -> then return init system.
>>>>
>>>> (III) Should no approaches provide an init system -> fail to return init
>>>> system.
>>>>
>>>> Comments
>>>> ~~~~~~~~
>>>>
>>>> This multi layered and comparing way of doing init systems may seem
>>>> complete overkill, or maybe its useful.
>>>>
>>>> What do you guys think?
>>>>
>>>> Best regards
>>>>
>>>> Owen
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>
> 

- -- 
SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB
21284 (AG
Nürnberg)

Maxfeldstraße 5

90409 Nürnberg

Germany
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJVUdWZAAoJECe/2BuiZiboAjwIAJGTYQZ20VLwExjFJHMeYtbO
MfeIPTYOc5DislnkjLWT2eUjgejqBR6Hg5pBcl+/Xw6i7CrTnpSk82dO//JvWjwo
bE2LHA/os0ssSivkzg2u1eslEYTEy1fspQzDiZv4k5L/6b+M9AAxkzxInYs8HUhi
KcOw2BB92SToOQPSLdRtRcYdpCILTKWALy3LzbySIJdZXAv0BD4EYiNJax7CWH+A
tfMmV1CTGduOCsAOmgTfFOcaL8DsDom4TSnp1Vqn2mNVEaChH4CmOpKsWW6ThXQ8
bjRhoTMZ20ZBbewfnfgulKMM1+tilnw4B4rA92F8ElfGgdrH49WvCLP8LjKD9EU=
=insW
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: autodetecting init system.

[Loic Dachary]

[-- Attachment #1: Type: text/plain, Size: 6314 bytes --]



On 12/05/2015 12:27, Owen Synge wrote:
> On 05/12/2015 11:45 AM, Loic Dachary wrote:
> 
> 
>> On 12/05/2015 09:56, Owen Synge wrote:
>>> On 05/11/2015 11:45 PM, Loic Dachary wrote:
>>>> Hi Owen,
>>>>
>>>> It would help to provide one or two use cases where (C) solves a problem 
>>>> that (B) (that is the current ceph-detect-init approach) does not
>>>> solve.
>>>
>>>> I sense there is something better in (C) but I can't think of a use case 
>>>> just now
>>>> (maybe because I've been thinking about erasure code all day :-).
>>>
>>> Hi Loic,
>>>
>>> Please note that I believe we are correct to explicitly allow the user
>>> to specify the init system and override any auto detection.
>>>
>>> Hence I believe it is correct for autodetection to be able to fail.
>>>
>>> Use case (1)
>>> ~~~~~~~~~~~~
>>>
>>> When a new release of an operating system comes out with a different
>>> init system (B) as a static database will not immediately account for
>>> this solution.
>>>
>>> For example
>>>
>>> SUSE SLE 11 -> sysV
>>> SUSE SLE 12 -> systemd
>>> RHEL 5 -> sysV
>>> RHEL 6 -> upstart
>>> RHEL 7 -> systemd
>>>
>>> When for example SLE12 came out ceph upstream code assumed ceph ran on
>>> the sysV init system until appropriate patches where taken.
> 
>> So Ceph failed to run on SLE12 because it was relying on sysV ?

That makes me curious about why it failed. There probably are similar problems with debian. Is there a tracker issue somewhere reporting this problem ?

> When we first released on SLE12 yes, I haven't yet checked the latest
> master.
> 
> Also if someone was "unusual" and used gentoo, mint, or other OS not in
> a database known OS, they might get "unusual" results.
> 
> This is a use case example the use case is maybe beter stated:
> 
> Handling of Operating systems which are not in the database of known
> operating systems.
> 
> Best regards
> 
> Owen
> 
> 
> 
>>>
>>> Since we can only test on "free as in beer" operating systems at this
>>> moment covering these OS's with the database and appropriate tests is
>>> problematic.
>>>
>>> Use case (2)
>>> ~~~~~~~~~~~~
>>>
>>> The use cases are on the latest debian, ubuntu platforms.
>>>
>>> On both these platforms you can install alternative init systems.
>>>
>>> on debian stable I can apt-get install the following init systems:
>>>
>>> systemd
>>> upstart
>>> sysvinit
>>>
>>> Hence assuming all debian stable systems are systemd (the default) is a
>>> false assumption as (B) does not support users changing the init system
>>> before installing ceph on debian and ubuntu as having a database of init
>>> systems cannot support all platforms.
>>>
>>> Use case (3)
>>> ~~~~~~~~~~~~
>>>
>>> By supporting (B) and (C) and emitting a warning on operating systems
>>> not in the database, populating the database will be quicker, and
>>> correcting values in the database will be easier to verify.
>>>
>>> In some ways, the code tests its self, at run time.
>>>
>>> Summary:
>>> ~~~~~~~~
>>> I think its a value decision, is the extra complexity of doing (B) and
>>> (C) worth the corner case of supporting the people who chose to use non
>>> default init system worth the code complexity. If we are supporting more
>>> than one init detection mechanism, it may well be worth supporting all
>>> of (A) (B) and (c).
>>>
>>> Best regards
>>>
>>> Owen
>>>
>>>
>>>
>>>> Cheers
>>>>
>>>> On 11/05/2015 18: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 see 4 ways I can see to detect init system.
>>>>>
>>>>> (A) Check pid 1.
>>>>> (B) Use a database of OS to init mapping / compile time.
>>>>> (C) look for init manipulation tools and infure the init system from tools.
>>>>>
>>>>> Comments:
>>>>> ~~~~~~~~
>>>>>
>>>>> (A1) systmd can be detected easily with.
>>>>>
>>>>>  grep -qs systemd /proc/1/comm
>>>>>
>>>>> (A2) With init scripts such as its hard to know what the init system.
>>>>>
>>>>> (B1) For operating systems like RHEL, SLE, CENTOS, Fedora and scientific
>>>>> linux this works well.
>>>>>
>>>>> (B2) FOr operating systems like newer debian and ubuntu releases more
>>>>> than one init system can be installed and used on the OS, so making a
>>>>> database / doing it at compile time are not practical on all OS's
>>>>>
>>>>> (C1) This is fairly reliable.
>>>>>
>>>>> (C2) sysV tools have compatibility scripts / programs on other platforms
>>>>> so if you use a points system for each init system helper script you can
>>>>> infure systemd over sysV if sytemctrl exists for example.
>>>>>
>>>>> So to summarise this:
>>>>> ~~~~~~~~~~~~~~~~~~~~
>>>>>
>>>>> (1) No one system is perfect in all cases.
>>>>> (2) Combined these systesm can provide reliable init system detection.
>>>>>
>>>>> My proposed approach.
>>>>> ~~~~~~~~~~~~~~~~~~~~
>>>>>
>>>>> (I) Use all three approaches where each approach can provide and answer,
>>>>> or fail to provide an answer.
>>>>>
>>>>> (II) Should any approaches disagree -> fail to detect init system.
>>>>>
>>>>> (III) Should all approaches agree -> then return init system.
>>>>>
>>>>> (III) Should no approaches provide an init system -> fail to return init
>>>>> system.
>>>>>
>>>>> Comments
>>>>> ~~~~~~~~
>>>>>
>>>>> This multi layered and comparing way of doing init systems may seem
>>>>> complete overkill, or maybe its useful.
>>>>>
>>>>> What do you guys think?
>>>>>
>>>>> Best regards
>>>>>
>>>>> Owen
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>
>>>
> 
> 
> 

-- 
Loïc Dachary, Artisan Logiciel Libre


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]