Re: autodetecting init system.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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@xxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux