Hacker News Reader

Hacker News

Comment by ranger_danger | Hacker News Reader

Full thread

ranger_danger

I know this article is for Windows, but if you're wondering if there's a way to do this on Linux, there is:

https://strace.io/

https://github.com/nelhage/reptyr

https://github.com/crigler/dtach

https://github.com/jerome-pouiller/reredirect

https://github.com/pasky/retty

View on HN

Thanks, links saved.

Then there is this method, but I guess that article refers to no redirection output.

If in background or via cron, I always redirect. But this is for UN*X type systems with a tail that supports '-f'

$ prog > /tmp/log.txt 2>&1 &

Then

$ tail -f /tmp/log.txt

Just so happens, I actually used this the other day for a long running process on OpenBSD :)

Isn't that what tee is for? Like

$ prog | tee /tmp/log.txt

That's if you start the process with advance knowledge that you'll want to tail the output and log it. Not if you want to view the output of an existing process

Yes, but I was replying to the above, using redirection and tail -f.

When I submit a process to bg, I mostly use cron and I do not care about seeing output during runtime.

So, tail suites my needs in the rare cases something unexpected seems to be happening.

Can't you just read from /proc/pid/fd/0 ?

This was my first thought as well. I assume somehow I'm the dummy that doesn't understand the question.

OpenBSD does not have a /proc file system.

Is there a way to read from present tty?

In practice: I boot into tty and manually start the graphical session (Wayland/Sway). I occasionally get (non-Sway) warnings when I return to tty (eg close the window manager). But the output is always scuffed, so I can't read the whole log. The lines get printed on top of each other or something.

Is there a way to read everything from tty, from within the tty?

Neither of the methods below work, because the warnings/errors aren't produced by Sway itself, but some other OS module/component.

$ sway |& tee /tmp/sway.log

$ tail -f /tmp/sway.log

It might be useful to try and figure out what's logging the messages.

However, if it was me, I'd strongly consider just starting from your shell in the tty, then running tmux, then starting sway, then attaching to tmux from a terminal emulator.

Thanks for your reply! I've thought about that as well. Haven't tried it though. Two thoughts about it:

1. Running graphical from within tmux feels unsafe (?). Introducing another layer can't be the way to go. BUT this comes from a position of limited knowledge, so I might stand corrected on this one. Also, doing it once for debugging won't do any harm.

2. I'm pretty sure the errors are not printed by Sway itself, but some other OS module. Errors that Sway cause for other modules won't be included in the Sway log. So the problem remains, no?

If things are printed on top of each other, try script?

https://man.freebsd.org/cgi/man.cgi?query=script&apropos=0&s...

But, if you're getting console debugs from the kernel, that wouldn't be captured either... Otoh, debug output from the kernel should also go into logs or dmesg or something?

You'll capture everything and maybe be able to figure it out from there?

Thanks for the input! Sounds promising. I've to admit, 'script' doesn't say anything to me yet. I've to look into it.

About the logs, yes, I have yet to dive into that. The _everything_ part makes it very tedious, so I had hoped for another solution :)

If script doesn't work, you could maybe try starting everything from within GNU screen or tmux with logging turned on?

These methods would fetch Sway error messages, but nothing else, no? This is not about Sway messages.

oh, one more thing... your pipeline is only capturing stdout; errors often get logged to stderr ... script (or screen/tmux logging) will capture both though.

Thanks for the notice! Embarrassing rookie mistake ;)

Here's my method using GDB from many years ago: https://gist.github.com/zaius/782263

vxworks 6.x:

(one login session, say over serial)

  -> ioTaskStdGet 0, 1
  value = 3 = 0x3
  -> taskIdSelf
  value = 13600784 = 0xcf8810

(another session, say over telnet)

  -> ioTaskStdSet 0xcf8810, 1, 0x9
  value = 0 = 0x0

(first session ie SERIAL)

  -> printf "foo\n"
  -> taskIdSelf
  -> i

(otherone eg TELNET)

  -> foo
  value = 4 = 0x4
  value = 13600784 = 0xcf8810


     NAME         ENTRY       TID    PRI   STATUS      PC       SP     ERRNO  DELAY
  ----------  ------------ -------- --- ---------- -------- -------- ------- -----
  ...

teeheeheehaw!

This prompted me to ask the crowd about a similar use-case of editing your command line as it's already running your command

https://news.ycombinator.com/item?id=46234678

I assume roughly the same caveats would apply, though? Buffering might be set wrong (and have no mechanism to be updated because the program never checks again), etc.

Reply on news.ycombinator.com