3

I want to set a timeout to the less(1) command on our company's production server. Everyday we produce large log files on it, and despite the nightly batch job to archive/remove them, we sometimes get alerted on high disk usage because a (long-)running process can prevent a file from getting unlink(2)-ed physically due to the reference-counting semantics of POSIX filesystems.

To avoid the most common cases of such annoyances, I wrote a wrapper of less which runs it under timeout(1) so that idle less processes get automatically killed after several hours without keeping open files in the filesystem.

But it turned out to play badly with man(1): when the wrapper is launched by the man command via the PAGER environment variable, it stopped responding to any keyboard inputs. Here is a minimal reproducible test case:

$ PAGER='timeout 12h /bin/less' man man

After running this, ps fx output looks like this:

19415 pts/1    SNs    0:00  \_ -bash
19854 pts/1    SN+    0:00      \_ man man
19867 pts/1    SN     0:00          \_ timeout 12h /bin/less
19869 pts/1    TN     0:00              \_ /bin/less

and I could only kill -KILL 19869 to regain an access to the terminal.

What did I get wrong here? Why is the less process in the T state, as opposed to S?

Improve this question
4
  • Show us the wrapper please
    – Rui F Ribeiro
    Jan 7, 2019 at 7:24
  • The only way I can reproduce this is if I temporarily put man/less in the background through Ctrl+Z. Did you do that to run your ps command? That would put less in a T state... Using timeout in PAGER seems to work as expected on my OpenBSD system.
    – Kusalananda ♦
    Jan 7, 2019 at 7:27
  • I suspect that the less process is getting suspended because it isn' in the foreground (so it receives SIGTTIN when it tries to read from stdin). @Kusalananda
    – Gilles 'SO- stop being evil'
    Jan 7, 2019 at 8:36
  • @Gilles Had you given a comment a bit earlier... I just posted my findings as a solution to my own question.
    – nodakai
    Jan 7, 2019 at 8:55

1 Answer 1

Reset to default
3

Answering to my own question, as I couldn't really find any hints on this via my googling.

strace(1) could actually reveal that SIGTTOU had been sent to the less process.

This is similar to SIGTTIN, but is generated when a process in a background job attempts to write to the terminal or set its modes. ...snip...

And apparently timeout(1) by default puts the process under management into background:

--foreground

Don’t create a separate background program group, so that the managed command can use the foreground TTY normally. ...snip...

So the solution to my problem was

$ PAGER='/bin/timeout --foreground 12h /bin/less' man man

(and something equivalent in my wrapper)

Improve this answer
5
  • Hmmm... I wonder it seemed to be working on my system then?
    – Kusalananda ♦
    Jan 7, 2019 at 9:02
  • 1
    @Kusalananda /usr/bin/man is a completely different beast on OpenBSD than on linux, especially since they got rid of groff.
    – user313992
    Jan 7, 2019 at 9:16
  • 2
    less still doesn't work right with timeout; when killed by a signal, less will fail to restore the stty/termios settings, and you will be left with having to do a blind reset or stty sane; try timeout 2s less ~/.bashrc.
    – user313992
    Jan 7, 2019 at 9:23
  • 2
    @mosvy this (minimal example) wrapper seems to fix it for me g=$(stty -g); timeout 2s less ~/.bashrc || stty "$g"
    – Chris Davies
    Jan 7, 2019 at 9:59
  • Nodakai, on my Debian version of timeout the man page and effect appear to contradict the GNU info page you referenced. With timeout 12h less the page works as I would expect - until the timeout gets reached. Specifically, the --foreground option is not required unless timeout itself is not being run directly from a terminal.
    – Chris Davies
    Jan 7, 2019 at 10:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .