I am running a server and the log of this server gets logged in terminal, not in any file. I would like to use less to view this log.

node server.js | less

When I just want to see the log, I use press Shift+F to got to end of file and keep watching logs. When I want to stop it, I use CTRL+C.

Unfortunately, this stops the server as well. I just want to stop watching the end of log without stopping the server.

How to do this?

  • 1
    Do you want to exit less and return to your shell prompt with the node server running in background, or do you just want to get less back into normal non-following mode where you can scroll through the log instead of watching the latest lines?
    – Byte Commander
    Apr 17, 2017 at 12:29
  • 1
    @ByteCommander when i press CTRL+C. i want my server to continue running and i want to got back to less normal non-following mode, where i can scroll.
    – Ajay Kumar
    Apr 17, 2017 at 12:34

3 Answers 3


I can't find any way of exiting the F mode in less, so you will have to use a workaround. For example, save the output to a tmp file and then watch that tmpfile instead:

node server.js > tmpfile & less tmpfile

The & makes the node.js command run in the background. This means that less tmpfile will start immediately and will be tracking the tmpfile.

Once in less, you can press F to enter follow mode but now Ctrl+C won't kill the server, it will only stop the follow. You can now scroll around as you would like and can hit F to resume following.


It seems that you are normally not supposed to exit "Forward forever" mode, which is how the manual man less names the mode you enter when pressing Shift+F.

However, I found a little dirty trick how you can return to normal anyway. It will briefly freeze the command though, so I am not sure if it would be suitable for your server which should probably run uninterruptedly.

Anyway, here is the trick:

I assume that you have started node server.js | less alredy and pressed Shift+F to enter "Forward forever" mode. Now less is not reacting to any keypresses any more.

In this state, you could press Ctrl+C to kill the server process and be able to quit less afterwards by pressing Q (which will however for some reason leave the command as stopped process in your jobs list - you have to run fg to continue it and let it completely terminate afterwards), but this is not what we want.

Instead, you can also press Ctrl+Z to stop ("freeze") the command and return to your shell prompt. Now quickly type the shell command fg ("foreground") to let the command continue running in foreground. Note that your node server process is also paused during this short time, you have to consider whether this is acceptable or not.

So now less is running in foreground again as before, right? Yes, but magically it is no longer in "Forward forever" mode. You can use e.g. the arrow keys again to scroll up and down.

Unfortunately, less seems to have stopped updating its buffer completely, you can only scroll down to the line at which you froze the command earlier, not any further. The node server is still running and producing output though, we just have to get less to refresh again.

The easiest way I found to do that is to simply open less' help screen and close it again, by pressing the keys H and Q sequentially. Now everything seems to be working fine again.

The cleanest solution however is probably to follow terdon's answer and redirect the output to a temp file, using less to monitor the file.

  • 1
    A rather brilliant dirty hack.
    – TRiG
    Apr 18, 2017 at 1:29
  • 1
    I think I prefer this answer to the accepted one. Note that you can run % rather than fg; I find it easier/quicker to type. Also it seems that F (shift-f) still works even without doing the hq trick. Nice! Now when I'm following logs, I can ctrl-z % Enter, do my less thing, then go back to following by hitting F!
    – JoL
    Apr 18, 2017 at 5:46
  • 2
    I haven't looked in the source, but this probably works because the TSTP signal interrupts the read system call that was waiting for new data to arrive; less receives 0 bytes and concludes that output has ended. To avoid pausing the server, open a new terminal window; execute ps and identify the process id of the less process; then type kill -TSTP <PID>; kill -CONT <PID>. This way the signals should get delivered back to back, without a delay while you're typing.
    – alexis
    Apr 18, 2017 at 11:08
  • 1
    @alexis if you're going to use kill, you can just send SIGINT instead. Then you won't need to send CONT, and less is just waiting for you.
    – muru
    Apr 18, 2017 at 13:00
  • 1
    Oh right, interesting suggestion. Try it, @Ajay! (However, my testing suggests that reading might not be resumed. Not sure what factors cause this.)
    – alexis
    Apr 19, 2017 at 12:36

As your question says:

This server gets logged in terminal, not in any file.

I assume that you don't want to use a (temp) log file, maybe your log is huge or for whatever reason you have.

Named pipe, fifo file.

What I came up with is using a named pipe file also known as fifo file, this file only will be used to pipe your logs to less, and nothing will be saved on it.

First create a fifo file:

mkfifo mylog

Run your server and redirect the logs to this file:

node server.js > mylog &

Use less to read your logs (-f forces less to read this special file):

less -f mylog

Now you can use shift+F to follow, and CTRL+C to stop the follow, but server is still running, you can follow the output again with shift+F.

Backup plan: If it stopped your server, just put your command (node server.js > mylog &) into a file e.g: server.sh, then instead of running node server.js > mylog & run: bash server.sh > mylog & and then run the less -f mylog.

  • What's the point of using a fifo instead of a regular file here? The only benefit I can see is to save on disk space but I doubt that will be relevant for something like this. You'll still have a file there after you're done which you will have to delete manually.
    – terdon
    Apr 17, 2017 at 22:03
  • 3
    I recommend against a FIFO here because the server process may stall if the FIFO buffer runs full when nobody requests (more) log data. If log file size is becomes an issue one should really use a proper log file plus logrotate. Apr 17, 2017 at 23:28
  • @terdon As you said the only point is saving disk, I thought the OP doesn't want his logs to be saved on the disk.
    – Ravexina
    Apr 18, 2017 at 8:18
  • @DavidFoerster +1 Good Point ;)
    – Ravexina
    Apr 18, 2017 at 8:19

You must log in to answer this question.

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