* Re: s6-ps [not found] <9f647c4c-2dc3-b977-928c-ee164ba88afe@ntlworld.com> @ 2019-01-05 0:20 ` Laurent Bercot 2019-01-05 4:04 ` s6-ps Jonathan de Boyne Pollard 2019-01-05 10:46 ` s6-ps Jonathan de Boyne Pollard 0 siblings, 2 replies; 17+ messages in thread From: Laurent Bercot @ 2019-01-05 0:20 UTC (permalink / raw) To: Jonathan de Boyne Pollard, Supervision >It occurs to me that s6-ps would gain from having an "exe" column. That functionality: - isn't available in procps. I modelled the available columns from procps' ones. Although that doesn't mean much, because there are many more columns available now in recent versions of procps than there are in s6-ps. - requires an extra system call per process: a readlinkat() on "exe". I tried to limit the functionality to what can be read in the "stat" file. Using "comm" as well was unavoidable, but annoying. That said, if there's demand for it, I'm not opposed to adding a column for exe. I just wasn't aware of people besides me actually using s6-ps. :) -- Laurent ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: s6-ps 2019-01-05 0:20 ` s6-ps Laurent Bercot @ 2019-01-05 4:04 ` Jonathan de Boyne Pollard 2019-01-05 10:46 ` s6-ps Jonathan de Boyne Pollard 1 sibling, 0 replies; 17+ messages in thread From: Jonathan de Boyne Pollard @ 2019-01-05 4:04 UTC (permalink / raw) To: Supervision Laurent Bercot: > That functionality: > - isn't available in procps. I think that you should not let that stop you. (-: Laurent Bercot: > I modelled the available columns from procps' ones. I think that you should not take that any further than you have already. This is the right point to stop. (-: You have a tool whose usage is a lot less messy, and a fair degree more straightforward, than that ps. You're fortunate *not* to have all of the quirky behaviours that I mentioned in the Stack Exchange answer. Having the three pieces of information in three columns with just three labels, without all of the ifs and buts, and having the environment strings be a column in their own right, and not an option that modifies another column's behaviour, is far simpler to explain. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: s6-ps 2019-01-05 0:20 ` s6-ps Laurent Bercot 2019-01-05 4:04 ` s6-ps Jonathan de Boyne Pollard @ 2019-01-05 10:46 ` Jonathan de Boyne Pollard 2019-01-05 14:41 ` s6-ps Jonathan de Boyne Pollard ` (3 more replies) 1 sibling, 4 replies; 17+ messages in thread From: Jonathan de Boyne Pollard @ 2019-01-05 10:46 UTC (permalink / raw) To: Supervision; +Cc: Shengjing Zhu Laurent Bercot: > I just wasn't aware of people besides me actually using s6-ps. :) I used it as an example of not being a mess. (-: s6 and s6-rc are actually ports/packages in FreeBSD and s6 is a package in Debian. Alas, the Debian world has not yet caught up with the other toolsets, and the third-party Debian packaging for s6-linux-utils and the others has yet to make it into Debian's own repository. * https://svnweb.freebsd.org/ports/head/sysutils/s6/ * https://svnweb.freebsd.org/ports/head/sysutils/s6-rc/ * https://packages.debian.org/sid/s6 * https://github.com/multiplexd/s6-packaging You could, in theory, make s6-ps not Linux-specific. It would require interposing a layer that abstracted reading the information out of the kernel, though. It's perhaps not worth it, because (for example) the FreeBSD ps is not nearly as encumbered by the mess that results from multiple personalities and Jack-of-All-Trades option parsing, albeit that it still has confusing column headings and does not have an env column. * https://unix.stackexchange.com/questions/492513/ ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: s6-ps 2019-01-05 10:46 ` s6-ps Jonathan de Boyne Pollard @ 2019-01-05 14:41 ` Jonathan de Boyne Pollard 2019-01-05 15:29 ` s6-ps multiplexd ` (2 subsequent siblings) 3 siblings, 0 replies; 17+ messages in thread From: Jonathan de Boyne Pollard @ 2019-01-05 14:41 UTC (permalink / raw) To: Supervision [-- Attachment #1: Type: text/plain, Size: 5525 bytes --] That said, I would probably write my own portable tool if it came to that, as my gripes with |ps| are not to everyone's tastes. * It is the 21st century. The FreeBSD, OpenBSD, and NetBSD |ps| programs all use |-| as the command-line option introducer, and have done since /at least/ BSD 4.4 Lite in 1994 <https://github.com/freebsd/freebsd/blob/e3cfc8ce61f788739c66445d903f8beacb40c93d/bin/ps/ps.c#L133>. A "BSD personality" that gives me the interface from the 1980s is not /actually/ a BSD personality that gives me |ps| as it exists and as I use it on the BSDs. This is neither compatibility nor interoperability. * The defaults are wrong. Much of my GUI is processes that run in dæmon context. By default, I /want/ to see processes in sessions that have no controlling terminal. The |-x| option is the wrong way around. * The defaults are wrong. Most of the time I want to see all users' processes. The |-a| option is the wrong way around. (Yes, most of the time I want to "see processes from other users" in Windows, too.) * Indeed, even in the unusual case where I am interested in only my own processes, my own processes /include/ set-UID processes spawned by processes running as my account, such as |urxvtd|, which is /my/ Unicode rxvt dæmon. * The defaults are wrong. Most of the time I do not want to see kernel processes. * When I use both the |comm| and |args| columns, I don't need an extra copy of the former put in brackets in the latter. * When I use the |comm| and |args| columns with |f|, I don't need both columns to have the tree diagram added to them, especially as it usually then obscures what is in the actual column, that I wanted to see. Notice how FreeBSD |ps| only puts the tree diagram in if |args| is the last column. Do that. * Your "BSD personality" should be giving me |-d| anyway, not |f|, as that is the actual option on the BSDs. I don't want a tool with Multiple Personality Disorder and Jack-of-All-Trades option parsing, though. I want a |ps| tool that is self-consistent and logical, with /one/ personality across all of the platforms that it works on, and /one/ way of doing most things (albeit allowing both short and long command-line options). * In fact, give me the tree diagram as its own, first class, column, as well. * My terminal emulators speak UTF-8 and have switchable fonts. Their grave accent sometimes really looks like a grave accent; and their minus sign sometimes really looks like a minus sign. Give me proper line drawing characters. It's ridiculous giving me a "BSD personality" from the 1980s and yet a TUI that does not even do TUI line drawing as well as it was done on MS/PC/DR-DOS in the 1980s. * The defaults are wrong. It is the 21st century. I haven't used a terminal with only the choices of 80 or 132 columns in years. Stop giving me 132 columns as the primary alternative behaviour. * The Single UNIX Specification has standardized the |COLUMNS| environment variable as a way for me to tell you how many columns I want, for many years, now. Don't give me idiosyncratic command-line option mechanisms of your own. Don't give me "It's unspecified.". Give me the |COLUMNS| environment variable. * The defaults are wrong. I'm piping your output through |less|, which knows how to sideways scroll. Release your right margin when standard output is not a terminal device. I do not need the final column to be of "undefined" width. I need it to be defined, as having unlimited width. For any column type, not just one or two of them. * Indeed, if I am piping output give me the option of releasing the width restrictions on all columns, not just the last one. I might want to have both the |env| and |args| columns, with neither truncated. * Don't give me |-u| , |-v| , |-l| , |-f| , |-j| and tell me that they are "user", "virtual", "long", "full", and "jobs", especially if you aren't going to give me long options or aren't even going to document what those are. Give me at the least a |--format| option that takes |user|, |virtual|, |long|, |full|, and |jobs|. Indeed, give me a |--format| option that has /all/ of the shorthands from |procstat|. (But that, unlike |procstat|, can combine with |-o| and itself rather than give me a mutually-exclusive choice amongst things none of which are /quite/ what I want.) * In fact, give me just |--output| for selecting columns individually and |--format| for adding predefined handy sets of columns, and allow them to combine as I see fit. * Give me |--no-headers| too. * Give me the option of TAB rather than SPC as column separator whilst you are at it. Then I can run it through tools that understand tables-of-one-line-per-record-with-TAB-separated-fields text. (No, I'm not grepping the process tree. I'm handling table formatting with generic tools for the job rather with your idiosyncratic mechanisms.) Give me |strvis(VIS_CSTYLE|VIS_WHITE)| on the field contents, so that the TABs and other whitespace are unambiguous. Indeed, give me the option of US as the field separator and RS as the record separator, and I can run it through tools that understand those. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: s6-ps 2019-01-05 10:46 ` s6-ps Jonathan de Boyne Pollard 2019-01-05 14:41 ` s6-ps Jonathan de Boyne Pollard @ 2019-01-05 15:29 ` multiplexd 2019-01-05 20:30 ` Can s6 be enough?: was s6-ps Steve Litt 2019-01-05 21:00 ` s6-ps Guillermo 3 siblings, 0 replies; 17+ messages in thread From: multiplexd @ 2019-01-05 15:29 UTC (permalink / raw) To: Supervision Hi all, (Apologies to JdePB, I accidentally replied to him directly instead of to the supervision list.) On Sat, Jan 05, 2019 at 10:46:29AM +0000, Jonathan de Boyne Pollard wrote: > Alas, the Debian world has not yet caught up with the other > toolsets, and the third-party Debian packaging for s6-linux-utils and the > others has yet to make it into Debian's own repository. > > * https://github.com/multiplexd/s6-packaging > Thanks for the advertising, Jonathan :-). I would, however, like to note that getting that packaging into the official Debian repos is not an immediate goal for me, as I don't have the time to commit to being a Debian package maintainer for the forseeable future. Cheers, --multiplexd. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Can s6 be enough?: was s6-ps 2019-01-05 10:46 ` s6-ps Jonathan de Boyne Pollard 2019-01-05 14:41 ` s6-ps Jonathan de Boyne Pollard 2019-01-05 15:29 ` s6-ps multiplexd @ 2019-01-05 20:30 ` Steve Litt 2019-01-05 21:22 ` Laurent Bercot 2019-01-06 15:03 ` Brett Neumeier 2019-01-05 21:00 ` s6-ps Guillermo 3 siblings, 2 replies; 17+ messages in thread From: Steve Litt @ 2019-01-05 20:30 UTC (permalink / raw) To: supervision On Sat, 5 Jan 2019 10:46:29 +0000 Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> wrote: > s6 and s6-rc are actually ports/packages in FreeBSD and s6 is a > package in Debian. Alas, the Debian world has not yet caught up with > the other toolsets, and the third-party Debian packaging for > s6-linux-utils and the others has yet to make it into Debian's own > repository. This brings up a question I've had for a long time. Three years ago I constructed an init consisting of Suckless Init as PID1 and s6 as the supervisor, which was called at the end of a simple rc file forked by Suckless Init. It worked just fine, without s6-rc or any other s6 products. From discussions with Laurent I got the idea that the main added functionalities of s6-rc are: 1) Process ordering during boot 2) Ability to intermix longruns with oneshots Everybody appreciates the preceding two features, but personally, I don't think they're absolutely necessary. Runit has neither, yet it works just fine for most things. When I first switched to runit, with its indeterminate ordering, I figured that with the dependencies I built into the run scripts, boot would resemble a field of mousetraps throwing ping pong balls. But that wasn't the case: runit brought everything up quickly and without trouble. So I'm thinking that although process ordering and intermixing are features we'd everyone likes, all but the most discerning among us could get along without them and therefore init with s6 alone. This is more than theoretical. As you remember, Debian's runit package manager wrote to ask about a minor problem with too many .u files and was contemplating changing some code, but nobody knew the code intimately, and runit is pretty much unmaintained at this point. So I suggested s6, which apparently has a Debian package but not one for s6-rc. My opinion is one can boot just fine with s6 alone, as long as you're willing to forego startup ordering and intermixing of longruns and oneshots, which by definition a runit fan is. So what do you all think? Is s6 a useful init system without s6-rc? Thanks, SteveT Steve Litt January 2019 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Can s6 be enough?: was s6-ps 2019-01-05 20:30 ` Can s6 be enough?: was s6-ps Steve Litt @ 2019-01-05 21:22 ` Laurent Bercot [not found] ` <20190106053901.GA16647@latitude.localdomain> 2019-01-06 15:03 ` Brett Neumeier 1 sibling, 1 reply; 17+ messages in thread From: Laurent Bercot @ 2019-01-05 21:22 UTC (permalink / raw) To: Steve Litt, supervision [-- Attachment #1: Type: text/plain, Size: 2722 bytes --] >Everybody appreciates the preceding two features, but personally, I >don't think they're absolutely necessary. Runit has neither, yet it >works just fine for most things. It really depends on what "most things" are. Small, server-only appliances? sure. Distributions where you can start all the oneshots first and all the longruns later? sure, but there aren't many of those. Typically udevd is a daemon you want to bring up very early, before some oneshots; so in the runit model, what do you do with udevd? Void Linux, which uses runit as its init system, has an answer to that: it doesn't supervise udevd. Don't you think that's ugly? Because I think that's ugly. >So I'm thinking that although process ordering and intermixing are >features we'd everyone likes, all but the most discerning among us >could get along without them and therefore init with s6 alone. Well yes. You can even get along with no supervision at all. Most people got along with sysvinit and sysv-rc just fine. The question is, do you want to? What do you expect from your init system? what functionality do you want to have, what functionality do you want your distribution to provide? > My opinion is one can boot just fine with s6 alone, as long as >you're willing to forego startup ordering and intermixing of longruns >and oneshots, which by definition a runit fan is. Yes, it can be done. As a matter of fact, it's completely trivial to take a Void Linux distribution and replace runit with s6. It works flawlessly. It just hasn't been done in the official Void distribution yet because the Void maintainers have other priorities, and runit works well enough for them. s6-rc and anopa exist for the people who are *not* willing to forego intermixing of longruns and oneshots. It all depends on what your priorities are, of what the aim of your distribution is. >So what do you all think? Is s6 a useful init system without s6-rc? Terminology, please! s6 isn't an init system per se. It's a process supervision system; and s6-rc is a service manager, aka machine state manager. Those are _components_ of an init system. You can build a complete, full-featured init system with s6 and s6-rc. You can also build an init system with s6 alone (and some scripting as s6-linux-init does), but it won't include a service manager. It's your call, really: I provide the mechanisms, distributions provide the policy. When they don't utterly give up on their duties, obviously. If you haven't watched it yet, please take a look at this video: https://archive.fosdem.org/2017/schedule/event/s6_supervision/ It's only 15 minutes long and explains all the terminology. -- Laurent ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <20190106053901.GA16647@latitude.localdomain>]
* Re: Can s6 be enough?: was s6-ps [not found] ` <20190106053901.GA16647@latitude.localdomain> @ 2019-01-06 7:40 ` Laurent Bercot 0 siblings, 0 replies; 17+ messages in thread From: Laurent Bercot @ 2019-01-06 7:40 UTC (permalink / raw) To: supervision >Eliminate dependency on udevd from oneshot startup scripts. One example among others: Kernel events are used to automatically load dynamic kernel modules. Say you need to mount a filesystem of a type that's not known in your core kernel, but you have a module for that. Either you manually modprobe everything in your initial oneshots (which is possible, but less flexible and more painful), or you just spawn udevd first and can then mount everything you need. The latter is clearly the intended use case - that's what automatic module loading is for. But you can only do that by making oneshots depend on the udevd longrun. Don't organize your system around the tools you have. You shouldn't have to jump through hoops to accommodate mediocre tools/architecture or distributor laziness; it's a losing game in the end, and the user is the one who loses. Instead, get the tools you need so your system works as painlessly as possible for the user. In some cases, you won't need a service manager; in most cases, you will. -- Laurent ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Can s6 be enough?: was s6-ps 2019-01-05 20:30 ` Can s6 be enough?: was s6-ps Steve Litt 2019-01-05 21:22 ` Laurent Bercot @ 2019-01-06 15:03 ` Brett Neumeier 2019-01-07 21:45 ` Steve Litt 1 sibling, 1 reply; 17+ messages in thread From: Brett Neumeier @ 2019-01-06 15:03 UTC (permalink / raw) To: Steve Litt; +Cc: supervision [-- Attachment #1: Type: text/plain, Size: 1350 bytes --] On Sat, Jan 5, 2019 at 2:30 PM Steve Litt <slitt@troubleshooters.com> wrote: > So what do you all think? Is s6 a useful init system without s6-rc? > My 0.02 USD -- based on my experience of setting up a simple GNU/Linux distribution from the ground up using s6, s6-rc, and s6-linux-init... - s6-rc provides useful functionality: it is really handy, when defining the way that the system should start up, to have bundles and oneshots; it is also really handy to be able to start up or shut down groups of processes via bundles. - The cost of using s6-rc is negligible. As installed on my x86_64 system with documentation, it consumes around 576 *kilobytes* of storage space. It compiles and installs in substantially less than a minute. Learning how to craft s6-rc service definition directories is no more difficult than learning how to craft s6 servicedirs. - You don't lose any capability provided by s6 if you also use s6-rc. You can send whatever signals you want to the supervised processes by using s6-svc directly. So ... costs ~= 0, benefits > 0, to me the question of whether s6 is useful _without_ s6-rc is kind of pointless. I'm inclined to turn the question around: what leads you to want to avoid s6-rc? Is there some other system that provides more benefits at lower cost? Cheers! Brett -- Brett Neumeier (bneumeier@gmail.com) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Can s6 be enough?: was s6-ps 2019-01-06 15:03 ` Brett Neumeier @ 2019-01-07 21:45 ` Steve Litt 2019-01-08 9:19 ` Laurent Bercot 0 siblings, 1 reply; 17+ messages in thread From: Steve Litt @ 2019-01-07 21:45 UTC (permalink / raw) To: supervision On Sun, 6 Jan 2019 09:03:33 -0600 Brett Neumeier <bneumeier@gmail.com> wrote: > On Sat, Jan 5, 2019 at 2:30 PM Steve Litt <slitt@troubleshooters.com> > wrote: > > > So what do you all think? Is s6 a useful init system without s6-rc? > > > [snip] > - The cost of using s6-rc is negligible. As installed on my x86_64 > system with documentation, it consumes around 576 *kilobytes* of > storage space. It compiles and installs in substantially less than a > minute. [snip] > > So ... costs ~= 0, benefits > 0, to me the question of whether s6 is > useful _without_ s6-rc is kind of pointless. > > I'm inclined to turn the question around: what leads you to want to > avoid s6-rc? 1) Apparently Debian doesn't yet have an s6-rc package 2) s6-rc adds more features and complexity I don't want to avoid s6-rc. If I had s6, I'd probably use s6-rc. But I have runit, which at a casual glance is like s6 without s6-rc, and everything works fine for me. When Debian acquires a properly working s6-rc package, the answer to my question degenerates to "why not?" But for now, for the Debian person who only installs via package, s6-rc is out of the question, so my question was, isn't s6 itself good enough? SteveT Steve Litt January 2019 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Can s6 be enough?: was s6-ps 2019-01-07 21:45 ` Steve Litt @ 2019-01-08 9:19 ` Laurent Bercot 0 siblings, 0 replies; 17+ messages in thread From: Laurent Bercot @ 2019-01-08 9:19 UTC (permalink / raw) To: Steve Litt, supervision >When Debian acquires a properly working s6-rc package, the answer to my >question degenerates to "why not?" But for now, for the Debian person >who only installs via package, s6-rc is out of the question, so my >question was, isn't s6 itself good enough? Then maybe you should ask Debian instead, "why aren't you packaging s6-rc?" It's literally a distribution's *job* to package software that may be useful to users. And instead, you are bending your mind to try and find justifications for users not to use some software, for the simple reason that it's not packaged by a distribution. That logic is 100% backwards. You want to help users? Package s6-rc for Debian. Also, call out Debian on their prejudice and disingenuous use of policies that prevent people from making correct execline and s6 packages. -- Laurent ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: s6-ps 2019-01-05 10:46 ` s6-ps Jonathan de Boyne Pollard ` (2 preceding siblings ...) 2019-01-05 20:30 ` Can s6 be enough?: was s6-ps Steve Litt @ 2019-01-05 21:00 ` Guillermo 2019-01-06 1:15 ` s6-ps Steve Litt 2019-01-06 7:06 ` s6-ps Colin Booth 3 siblings, 2 replies; 17+ messages in thread From: Guillermo @ 2019-01-05 21:00 UTC (permalink / raw) To: Supervision El sáb., 5 ene. 2019 a las 7:46, Jonathan de Boyne Pollard escribió: > > * https://packages.debian.org/sid/s6 And buster too. Which has the side effect of making it automatically available in Devuan ceres and beowulf :) * https://pkginfo.devuan.org/cgi-bin/d1pkgweb-query?search=s6_2.7&release=any I don't know why execline is a 'recommends' though. It should be a 'depends', I believe. G. G. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: s6-ps 2019-01-05 21:00 ` s6-ps Guillermo @ 2019-01-06 1:15 ` Steve Litt 2019-01-06 7:06 ` s6-ps Colin Booth 1 sibling, 0 replies; 17+ messages in thread From: Steve Litt @ 2019-01-06 1:15 UTC (permalink / raw) To: supervision On Sat, 5 Jan 2019 18:00:57 -0300 Guillermo <gdiazhartusch@gmail.com> wrote: > I don't know why execline is a 'recommends' though. It should be a > 'depends', I believe. I set up a s6 supervisor using all shellscripts and no execline. You don't absolutely need execline. SteveT Steve Litt January 2019 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: s6-ps 2019-01-05 21:00 ` s6-ps Guillermo 2019-01-06 1:15 ` s6-ps Steve Litt @ 2019-01-06 7:06 ` Colin Booth 2019-01-06 7:30 ` s6-ps Laurent Bercot 1 sibling, 1 reply; 17+ messages in thread From: Colin Booth @ 2019-01-06 7:06 UTC (permalink / raw) To: supervision On Sat, Jan 05, 2019 at 06:00:57PM -0300, Guillermo wrote: > El sáb., 5 ene. 2019 a las 7:46, Jonathan de Boyne Pollard escribió: > > > > * https://packages.debian.org/sid/s6 > > And buster too. Which has the side effect of making it automatically > available in Devuan ceres and beowulf :) > > * https://pkginfo.devuan.org/cgi-bin/d1pkgweb-query?search=s6_2.7&release=any > > I don't know why execline is a 'recommends' though. It should be a > 'depends', I believe. > > G. libexecline is a runtime requirement for s6-log if linked dynamically. It's also a compile time requirement for roughly the same reason. Assuming a static (or mostly static) compilation of the s6 suite, execline is correctly marked as a recommendation. Looking at the package in Unstable, zhs has split libexecline from the execline binary suite and dynamically compiled things. Therefore, installing s6 forces installation of libexecline, libskarnet, and libs6, and recommends the execline bundle. Cheers! -- Colin Booth ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: s6-ps 2019-01-06 7:06 ` s6-ps Colin Booth @ 2019-01-06 7:30 ` Laurent Bercot 2019-01-06 18:07 ` s6-ps Colin Booth 0 siblings, 1 reply; 17+ messages in thread From: Laurent Bercot @ 2019-01-06 7:30 UTC (permalink / raw) To: supervision - The execline library is required to build a few of s6's utilities (typically: s6-ftrig-listen). - The execlineb binary is required for use of the !processor directive in s6-log. - Some of the other binaries provided by execline are used by s6 utilities, for instance s6-fdholder-store. "Recommends" is a mistake. Without execline, parts of the s6 suite of programs will break. -- Laurent ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: s6-ps 2019-01-06 7:30 ` s6-ps Laurent Bercot @ 2019-01-06 18:07 ` Colin Booth 0 siblings, 0 replies; 17+ messages in thread From: Colin Booth @ 2019-01-06 18:07 UTC (permalink / raw) To: supervision On Sun, Jan 06, 2019 at 07:30:21AM +0000, Laurent Bercot wrote: > > - The execline library is required to build a few of s6's utilities > (typically: s6-ftrig-listen). > - The execlineb binary is required for use of the !processor directive > in s6-log. > - Some of the other binaries provided by execline are used by > s6 utilities, for instance s6-fdholder-store. > Ah, good point. I was misremembering and thought s6-log processed the command string itself but used libexecline to teach it how, similar to s6-ftrig-listen's dependency. Looking a bit closer, the one that's going to break the hardest for people using s6 solely as a supervisor is s6-notifyoncheck since you can inline a check program with the -c option. I'm not sure how many people go that route who aren't already going to have execline installed, but it's something that will definitely cause some ill will. > > "Recommends" is a mistake. Without execline, parts of the s6 suite > of programs will break. > > -- > Laurent > -- Colin Booth ^ permalink raw reply [flat|nested] 17+ messages in thread
* s6-ps @ 2019-01-04 9:18 Jonathan de Boyne Pollard 0 siblings, 0 replies; 17+ messages in thread From: Jonathan de Boyne Pollard @ 2019-01-04 9:18 UTC (permalink / raw) To: Supervision * https://unix.stackexchange.com/a/492346/5132 It occurs to me that s6-ps would gain from having an "exe" column. ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2019-01-08 9:19 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <9f647c4c-2dc3-b977-928c-ee164ba88afe@ntlworld.com> 2019-01-05 0:20 ` s6-ps Laurent Bercot 2019-01-05 4:04 ` s6-ps Jonathan de Boyne Pollard 2019-01-05 10:46 ` s6-ps Jonathan de Boyne Pollard 2019-01-05 14:41 ` s6-ps Jonathan de Boyne Pollard 2019-01-05 15:29 ` s6-ps multiplexd 2019-01-05 20:30 ` Can s6 be enough?: was s6-ps Steve Litt 2019-01-05 21:22 ` Laurent Bercot [not found] ` <20190106053901.GA16647@latitude.localdomain> 2019-01-06 7:40 ` Laurent Bercot 2019-01-06 15:03 ` Brett Neumeier 2019-01-07 21:45 ` Steve Litt 2019-01-08 9:19 ` Laurent Bercot 2019-01-05 21:00 ` s6-ps Guillermo 2019-01-06 1:15 ` s6-ps Steve Litt 2019-01-06 7:06 ` s6-ps Colin Booth 2019-01-06 7:30 ` s6-ps Laurent Bercot 2019-01-06 18:07 ` s6-ps Colin Booth 2019-01-04 9:18 s6-ps Jonathan de Boyne Pollard
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).