From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2408 Path: news.gmane.org!.POSTED!not-for-mail From: Guillermo Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: More Answers Date: Mon, 24 Dec 2018 14:10:20 -0300 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1545671311 23594 195.159.176.226 (24 Dec 2018 17:08:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 24 Dec 2018 17:08:31 +0000 (UTC) To: Supervision Original-X-From: supervision-return-1998-gcsg-supervision=m.gmane.org@list.skarnet.org Mon Dec 24 18:08:27 2018 Return-path: Envelope-to: gcsg-supervision@m.gmane.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1gbTiL-0005y9-J3 for gcsg-supervision@m.gmane.org; Mon, 24 Dec 2018 18:08:25 +0100 Original-Received: (qmail 13378 invoked by uid 89); 24 Dec 2018 17:10:57 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 13371 invoked from network); 24 Dec 2018 17:10:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=Iw+W9MW2AKOV6O5++0SykgmBHtYkOpP2ULOhpLtonLw=; b=QLUR+quuwBkJcEfEC9dW9NhuNzlEIyPWKjEVnNahtOWTuSLpWIUpVnvO7FgKWOVSnr /yYen0pH/WtORUsim/M6ofeMR4OMAwCmLd7xmn5wjE1di8tAIB9sbiwkEBIlzPKWqqJ3 NbWZizhUD+DBFZw3GqxiWI+6BzEWiPIZUMp/KwR5WHGixCAlBOBpLK5hJ126G536hhX/ 7GCWBrq845A8Mobqs/u3fuRlZA4oQC4ssnBy88nkO+eErsXqxM64adjDRIkQmX3wTFoG T4d7lDIRkK/uLdt7A8Dsmiu44SqjASX3Tdx/vCGpK+b+Ij9LYjq1jac9zpo57805GDUG /qxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=Iw+W9MW2AKOV6O5++0SykgmBHtYkOpP2ULOhpLtonLw=; b=qncjybQChteC4V6QFFwYBl6NF26/NlkzbtersWOdru/J6uxciM8w813p9unMdVcNFE nzad16c0NP0tejmKkfViaq0CxschP6jvBU+zqm90ewsSR37GnQ/K4pErWhjBew7Hg0hH RNe93ldjmKNFm3qmHXQFDDkIW5/cvJ+UjqaXWF0B7J7w54mdxcAZ/HvNQfvwYaUs+kh/ g1n7lgX8OT+jenSEv4fOtFsS/FyJS3kmpNXoNMgMgApe/TTIK2JLasjP6K9azlrGWbdc 5R0MhPQEfrPs+VsgcvE+oeaDBcA/a2vp4w+H4Ih2yVQcaeLEpoqzsYGr82nKWuYwUDVG i6HQ== X-Gm-Message-State: AA+aEWb1XRYLMDrvMWRGKc9JQZcxjgf6SnW+xcTZCIhN40NaeCTQLXiv hjAQvlRRJOdBv6vIgqO5M1I4eizw7IUh40PNaWVnEw== X-Google-Smtp-Source: ALg8bN4fhKQhNIDszfVsYdK2vB9kIXiD2VL92je8oGWPS5NauAPx6BxrQXJOvFxr7elH7GLnk24mwm3qjwBh1i454Kc= X-Received: by 2002:a05:660c:4c5:: with SMTP id v5mr9545636itk.104.1545671428591; Mon, 24 Dec 2018 09:10:28 -0800 (PST) In-Reply-To: Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2408 Archived-At: El lun., 24 dic. 2018 a las 7:10, Laurent Bercot escribi=C3=B3: > > >* https://unix.stackexchange.com/a/489949/5132 > > > >This may be of interest to people looking for some (brief) comparative a= nalysis. Including the further reading. (-: > > Thanks for the heads-up! I posted an answer in complement to yours. > > We really need to settle on some terminology. I don't like your > use of "service manager" to mean "supervision system", and your use > of "system manager" to mean what I call a "service manager" is meh. > > I'd be okay to ban the "service manager" terminology entirely because > it's confusing, and use "supervision system" and "state manager" (which > sounds better than "system manager" to me) instead. Thoughts? I also find clearer and personally prefer the terminology used in the skarnet.org documentation. The 'service/machine state manager' and 'process supervision suite/system' distinction captures details such as that the former takes into account service interrelationship (service dependency being the first form of it that comes to mind), whereas incarnations of the latter I know of do not (by themselves). But 'service manager' ("something that manages services") is in too widespread use to be banned :P I have no problem with the term being used to designate something like OpenRC or s6-rc, though. The 'system manager' and 'service manager' terminology is used in systemd documentation (as in "systemd is a system and service manager for Linux operating systems", found in the man page for the systemd program), although I don't know if the terms are given some specific definition somewhere or just used generically. I'm not sure that what is being described in the Stack Exchange answer as the "system manager r=C3=B4le" maps to a service manager in the s6-rc sense. Especially the "generally is run as process #1" because "the kernel of the operating system treats it specially, sending it information about system state change requests" part. And the fact that it is being applied to nosh's system-manager program and to the van Smoorenburg init program. System state changes are mentioned, but two aspects are involved: triggering them in response to something and actually performing them. I read the answer as mostly referring to the former? I mean, with a sysvinit + OpenRC setup, it is indeed process 1, the init program, that triggers a state change (e.g. by spawning a child process configured in /etc/inittab in response to Ctrl + Alt + Del or the administrator using the shutdown program), but the openrc program that performs it (by executing service scripts in /etc/init.d). With an s6 + s6-rc setup, it is process 1, s6-svscan, that triggers a state change (e.g. by spanwing .s6-svscan/SIGINT or .s6-svscan/SIGUSR1 processes in response to Ctrl + Alt + Del or the administrator using the s6-poweroff program from s6-linux-init), but the s6-rc program that performs it. And with a nosh setup, it is process 1, system-manager, that triggers a state change, but its system-control child processes that perform it. Using the skarnet.org definitions, service-manager, the program, is a process supervisor (of multiple process rather than just one like s6-supervise, or at most two, like runsv), and the service manager concept is implemented by system-control :D Or rather, a subset of its subcommands that includes 'start' and 'stop'. I'll also point out that OpenRC does have a PID 1 program since version 0.25 named openrc-init, and an accompanying openrc-shutdown program. BUT... it has the problem of not supervising some other process, and therefore making the machine unusable and in need of a reboot if all processes except #1 die. I don't know of any distribution that doesn't use OpenRC in combination with something else as the PID 1 program, though, at least as a supported/default setup. G.