From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2768 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Jan Braun Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: s6 usability Date: Sat, 21 Dec 2019 12:49:39 +0100 Message-ID: <20191221114939.lqzru5vlvv6uyyyh@klumpi.ignorelist.com> References: <20191125214342.y7lx5mixrljr6s27@gromit.local> <20191127203307.ohaameqfgncm52h5@gromit.local> <20191129140901.klifpegc74iv4zul@klumpi.ignorelist.com> <20191201214752.2ec0a81b@mydesk.domain.cxm> <337de051-b2b4-4f69-78e7-3f737f40384f@sholland.org> <20191203171020.2a4e9a92@mydesk.domain.cxm> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="raxanvqj3e4i652x" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="34743"; mail-complaints-to="usenet@blaine.gmane.org" Cc: supervision@list.skarnet.org To: Steve Litt Original-X-From: supervision-return-2357-gcsg-supervision=m.gmane.org@list.skarnet.org Sat Dec 21 12:49:45 2019 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.89) (envelope-from ) id 1iidGT-0008wk-3U for gcsg-supervision@m.gmane.org; Sat, 21 Dec 2019 12:49:45 +0100 Original-Received: (qmail 13268 invoked by uid 89); 21 Dec 2019 11:50:09 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Original-Received: (qmail 13261 invoked from network); 21 Dec 2019 11:50:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576928980; bh=PnU5cvpLjZUjLqb43xs3NV3uots4YvM3mAberM8ERWA=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:References:In-Reply-To; b=NenzSWLpZ3ypxNM2drsT78RsZXs4xF1qFW1ymY0dxiNQqEqNLxAl49UKLPekIo2Yo seXi8tmI59WsezizHaUGfbGos+20dXG8fJeTV0jX2yzbkvXjMeuJV7FqD5k6a9qYL6 zZebFC8ZNZPpcILzK7+vh0ySacSNEmQfrSDz+lWU= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Mail-Followup-To: Steve Litt , supervision@list.skarnet.org X-GPG-Fingerprint: 1736 D50F 170B 70A6 9223 BC15 295E 703E 6D1D 2FCF X-GPG-Encryption-Welcome: always Content-Disposition: inline In-Reply-To: <20191203171020.2a4e9a92@mydesk.domain.cxm> X-Provags-ID: V03:K1:hl/gQD/9Kk3gruv4tIAicyi3aTUK1Bgg9iRxOUe7jqCMPGhYCh9 M7ebqEzMAj8NIGkqnbUbkcEkluBR7ObPEsQckEFNZLyLXQMk5iYw5GoaX1ClvUaTbaDjfWo 8mnl1TihUf0jTksl5nSK1MQMMnEa7r44HAho8jlbIP6ifgih/Bxoy2ug8oRA+NdPowcAa3i EzXb0ktw/+5yJl8vXlmTg== X-UI-Out-Filterresults: notjunk:1;V03:K0:WZTr5VrdTz0=:F733c643+O+yC8AzPN7/Ht DaTbjvGWL+ChdHLgCsUkz4k+ZaLTiEhMZDhAQFeyKaRBJAzvsfWpef6zGya6Y8MzAg39sjUI5 BgjUJgJFv3qrNIpYIsYuUeYIaYUivOts0gMGsifuQk1D5Fm48HxykC6EWjafFfu4uBk181cj9 WEx5sqtraVXEzguRdzlgkYsQpp0QC668judPwEgr/rRrlHcNGQatis5Br9b5gCuPpT/3FifZB nlH0dvfvr0g0hETPVDh304Kfa8vO6fJItIS9rcrK3InsmJB2J6qnc25aKfCL5NwAVJyUXsWTs E5GLE79+ZFQOGDdmC9/UIcyA8owqHz09eq0DRwLUdeLLOfC4EV1nIeRxjQVMTTOlHmK33qJlR G7W0ncUo02Q2EL5Srb5nVSuYPQpRxNvRDTltoyyJNmBDz3T22CxVJsihBUk+xV7XsjBanWuyt cpAFgloiIcxT6sB5cGR1QYDwW9VXrsnBqpqYeJeeb48Ne2V+UVaNKfqA26pAo5uugn6VNRDkh dwoiOxzYHhHD5b3YI3Oh55xWqPxm0ef9toIYp5AFLRRnUegLL2MAlq+8gWnvuHVkijc3lCE6p kS3F9MBBWAmwJwCx2Zh26MtHR/IETTiPkyffhYEuYoTYBooxoCuUmpLtIFtUAZOi5frUSIGFo W5GGO5PGAJ6hjMl/MP243h4rq2iwTcWctBC6CbSkA6asv1hxV9SD51bTpPtSLY73T0y5SDWKK ebfbhrAzBjTn/ftEw9RwErsE+I+TOmSifMA+6qw6qWMaxVenAZWN2Fe6P4yjlUvXQ/uEn7IZ Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2768 Archived-At: --raxanvqj3e4i652x Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Steve Litt schrob: > > From a Linux distribution perspective, there's also the question of > > if s6 can be made a drop-in replacement for daemontools, [...] >=20 > In my opinion, 99% of all people currently using daemontools are highly > technically proficient and could easily either rename commands or > prepath to a directory containing prefixless symlinked synonyms. IMHO > if the distro does it, they'll find a way to screw it up. And even if > the distro does it right, it will screw that 1 in a million people > (like me) who occasionally use daemontools and s6 on the same box, > switching between them regularly. I find these claims to be rather unplausible, given my Debian experience. The Debian way would be creating a package "s6-daemontools" containing just the symlinks from foo to s6-foo and declaring the following package relationships: Depends: s6 Conflicts: daemontools Provides: daemontools That is, when s6-daemontools is installed: s6 must also be installed, daemontools must not be installed, but daemontools is treated as installed for dependency purposes. Then, you can choose to install s6 and daemontools together, getting the default naming for each. And I can install s6-daemontools and get tai64n/tai64nlocal binaries that produce correct timestamps despite my kernel clock being set to UTC. (That is, the ones from s6.) And every dependency on "daemontools" will be fulfilled, by exactly one of either djb's daemontools, or s6 plus the symlinks in s6-daemontools. See espeak-ng-espeak for a real package like that. This is hardly rocket science, and has been done for *decades* by now. Maybe non-Debian(-derived) distros are in the business of doing stupid sh*t, but then you should either switch to a sane distro or be building your own system. It's certainly no reason to refuse to consider the "s6 as daemontools" concept. Or to insist that people must setup the symlinks themselves. Onwards: Comparing the debian daemontools package with s6 gives: | $ dpkg -L daemontools | grep /usr/bin/ | sed -E 's_/usr/bin/_/usr/bin/s6= -_' | xargs ls -1 | ls: cannot access '/usr/bin/s6-multilog': No such file or directory | ls: cannot access '/usr/bin/s6-pgrphack': No such file or directory | ls: cannot access '/usr/bin/s6-readproctitle': No such file or directory | ls: cannot access '/usr/bin/s6-svscanboot': No such file or directory | /usr/bin/s6-envdir | /usr/bin/s6-envuidgid | /usr/bin/s6-fghack | /usr/bin/s6-setlock | /usr/bin/s6-setuidgid | /usr/bin/s6-softlimit | /usr/bin/s6-supervise | /usr/bin/s6-svc | /usr/bin/s6-svok | /usr/bin/s6-svscan | /usr/bin/s6-svstat | /usr/bin/s6-tai64n | /usr/bin/s6-tai64nlocal | $=20 As Laurent said in the other mail: > s6-setsid can be symlinked as pgrphack [...] > s6-log can be symlinked as multilog. That leaves only readproctitle and svscanboot. The latter is just clearing env, setting $PATH and executing svscan /service 2>&1 | readproctitle service errors: ..... with 400 dots, according to the manpage. But I don't think there's an equivalent of readproctitle in s6. Plus, there remains the issue of non-compatible supervise directories. I don't think the above packaging scheme is valid if it would mean services (with their existing supervise dirs) fail to work because the supervise(8) implementation got switched from djb to s6 or vice versa. But in my quick testing they actually could re-use each other's supervise dir without tripping over the other implementation's artifacts.=B9 Laurent, is that something that should work/you are willing to support? In that case, readproctitle would be the only remaining obstacle. regards, Jan =B9 They would not recognize each other's locking, however. --raxanvqj3e4i652x Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEFzbVDxcLcKaSI7wVKV5wPm0dL88FAl3+Bs4ACgkQKV5wPm0d L89nAQ//XsPHF2WG4xSCq3m13RFnFIR3B48OkGQrh4J4ezBF4s4Em+Ye/f8Brr0m 9SCWLOnXXwK4ocSw6/RZdPuT2IqTA70NPEL4uR65uG0uPEng+sJUJkdPHva3UGUI kmUsFMxEwsuHnZh8u/AmmAHYULBnqUddQM5MAD+f0MRIZc4BVEcwr/87M7Wr3g/Z UqWKwQmYGsS3V/DrnlTcZgM41DrhbZep20Kdd9JjeuZc2lBIFilGOMkmzl7tN7I9 fchBKWepPJAVLV8qY4yRAPuj9mkKm9pEYRv/NzC+IpZr5GvcntwSDVitwWy0wmGh eDz9+1xwqSH8MXqFbxt3QCbAWhCEiJVT+PcBYZ5gK+Aw9kCMudmtty8QnitqAocb 7mVEsz+fx1DUgKh25Nf0iSaQlDv/UqJ5IevYgMO8F+yQ5KgsqEg4W9wdsnc6w2Cn FBuIhA5sx65+YfnhLAnEYzZly+BmwgdvGK/6qbyoGPYljwOpzNOF5EwbOfzP4GhP Uwk9M71by4ooWrTzX+mL4eYTQdTiQnVi1d0UV/krXJkFs5OMDQyk9AunlPmcsMtp RKG4mgpOJ2A18rYpgUYrPchXX2q6jkQgHNbD+HYBBDW+qgFsfQOoMhn+JG+1fppx wURid8d+W0o3hFcxiLQYOwuZMaus40jRPa4LKdscWWZhCSyP4Wg= =NBel -----END PGP SIGNATURE----- --raxanvqj3e4i652x--