| ▲ | ranger_danger 4 days ago |
| 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 |
|
| ▲ | jmclnx 4 days ago | parent | next [-] |
| 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 :) |
| |
| ▲ | smcameron 4 days ago | parent | next [-] | | Can't you just read from /proc/pid/fd/0 ? | | |
| ▲ | irishcoffee 4 days ago | parent | next [-] | | This was my first thought as well. I assume somehow I'm the dummy that doesn't understand the question. | |
| ▲ | jmclnx 3 days ago | parent | prev [-] | | OpenBSD does not have a /proc file system. |
| |
| ▲ | hmng 4 days ago | parent | prev [-] | | Isn't that what tee is for? Like $ prog | tee /tmp/log.txt | | |
| ▲ | jmclnx 4 days ago | parent | next [-] | | 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. | |
| ▲ | gosub100 4 days ago | parent | prev [-] | | 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 | | |
| ▲ | hmng 4 days ago | parent [-] | | Yes, but I was replying to the above, using redirection and tail -f. |
|
|
|
|
| ▲ | zaius 4 days ago | parent | prev | next [-] |
| Here's my method using GDB from many years ago: https://gist.github.com/zaius/782263 |
|
| ▲ | maxjohan 4 days ago | parent | prev | next [-] |
| 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 |
| |
| ▲ | toast0 4 days ago | parent | next [-] | | 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? | | |
| ▲ | maxjohan 4 days ago | parent [-] | | 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 :) | | |
| ▲ | ranger_danger 4 days ago | parent | next [-] | | If script doesn't work, you could maybe try starting everything from within GNU screen or tmux with logging turned on? | | |
| ▲ | maxjohan 3 days ago | parent [-] | | These methods would fetch Sway error messages, but nothing else, no? This is not about Sway messages. |
| |
| ▲ | toast0 4 days ago | parent | prev [-] | | 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. | | |
|
| |
| ▲ | yjftsjthsd-h 4 days ago | parent | prev [-] | | 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. | | |
| ▲ | maxjohan 4 days ago | parent [-] | | 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? |
|
|
|
| ▲ | baobun 4 days ago | parent | prev | next [-] |
| 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 |
|
| ▲ | mzs 4 days ago | parent | prev | next [-] |
| 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! |
|
| ▲ | glhaynes 4 days ago | parent | prev [-] |
| 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. |
