s6-ps

s6-ps

[Jonathan de Boyne Pollard]

* https://unix.stackexchange.com/a/492346/5132

It occurs to me that s6-ps would gain from having an "exe" column.

Re: s6-ps

[Laurent Bercot]

>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

Re: s6-ps

[Jonathan de Boyne Pollard]

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.

Re: s6-ps

[Jonathan de Boyne Pollard]

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/

Re: s6-ps

[Jonathan de Boyne Pollard]

[-- 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.

Re: s6-ps

[multiplexd]

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.

Re: s6-ps

[Guillermo]

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.

Re: s6-ps

[Steve Litt]

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

Re: s6-ps

[Colin Booth]

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

Re: s6-ps

[Laurent Bercot]

  - 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

Re: s6-ps

[Colin Booth]

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