What do people (you) think about browser based log viewers like e.g. logio.org? I like to comfortably have all the logs in the browser but do not want to go full ELK (or anything in this category) stack just for a few servers. But I am not sure if there is some better solution? Multitail is great, but sometimes just opening a new browsertab is even greater...
Stop using tail -f (mostly)
131–140 of 211 posts
Re: Stop using tail -f (mostly)
#132It's amusing to read this just as, for the first time in months, I have a "tail -f" running. I just converted a medium-sized system from Python 2 to Python 3 (this is not fun; I had to fix or work around five bugs in external modules), and deployed it this morning. So I have a "tail -f" running in "putty", watching an Apache server error log. (I know, retro.) This is just in case there's some new Python-level error; operational errors are logged to the database. The log is quiet, and soon I can stop watching.
Re: Stop using tail -f (mostly)
#133Earlier quoted context omitted.
On large files less fires up immediately and vim is quite slow. I think that vim is loading an entire file in the memory while less just loads visible chunk. May be other vi implementations are more efficient with large files. Besides — vim really shouldn't be used on log files. It's editor, not viewer.
> Besides — vim really shouldn't be used on log files. It's editor, not viewer. I think the two concerns I stated are probably legit, but this one is boring to me. Vim is nicer than less for reading files. I have more navigation commands. I can yank part of the file and save it somewhere else. I can pipe a range of lines through awk/etc. I can switch between files. I can split my screen. Etc. Some of these are probab…
You can save a part of the file, pipe a range of lines, or switch between files in less, too, and the commands are mostly the same as in vi. It'd sure be nice to be able to split the screen, though!
Re: Stop using tail -f (mostly)
#134Re: Stop using tail -f (mostly)
#135Earlier quoted context omitted.
An example of some of the vi commands that less(1) has adopted. You can also: * page forward and backward, including using numeric prefixes to indicate a lineno or indicate "repeat 'n' times". * launch vi if less(1) is working on a file (versus (eg) stdout of some process) * search fwd/backward * start examining a new file w/o leaving less(1) * ...
Just the other day I was looking for a way to do this in less: yank 10 lines, open a new file, paste the 10 lines, save the file. Is that possible? My Googling last week didn't find a good solution.
Usually I `ma|acat > newfile` in less, which saves by default a whole screenfull. There must be a better way to do this in less.
Re: Stop using tail -f (mostly)
#136Earlier quoted context omitted.
This is not a replacement for searching for a specific string in `less` which highlights the matches, and eliminates the need for scanning the text manually which is harder and prone to missing information.
Correct, however the author is saying that there's no reason to ever use tail unless you're tailing multiple files, which is false. Most of the functionality you want is already built into your terminal emulator. If you want slower updates (`less` uses 1 second polling, vs `tail` [inotify]), and the ability to search, by all means, use `less`.
Hmm, someone should add inotify handling to `less`.
Re: Stop using tail -f (mostly)
#137Earlier quoted context omitted.
on OpenBSD -f does: Do not stop when end-of-file is reached, but rather to wait for additional data to be appended to the input. If the file is re- placed (i.e., the inode number changes), tail will reopen the file and continue. If the file is truncated, tail will reset its position to the beginning. This makes tail more useful for watching log files that may get rotated. The -f option is ig- nored if the standard in…
Is there a bug report open for that yet? FreeBSD has this so they should be able to resync easily enough
I don't think its a bug
Re: Stop using tail -f (mostly)
#138I use tail -f with tmux usually. Will less +F save the entire output into memory? In other words, if I accidentally leave it open in a tmux shell and the log grows to 300mb of output, will the server start swapping?
I usually run `less` niced and with a ulimit of 30 megabytes, but `less` also has an option to configure how much buffer space to use. As far as I can tell, the default is "all of your memory", which is a suboptimal default in my book.
Re: Stop using tail -f (mostly)
#139Be very, very careful with this: http://seclists.org/fulldisclosure/2014/Nov/74 But really, it's 2015. Are you really using a terminal emulator without a buffer search? Are you not using screen or tmux, both of which can do these things natively, with no external tools? Why? And what is wrong with backgrounding the tail command, running your grep, and then foregrounding the tail command?
Personally? The reason I'm not using screen is that there's no way to atomically [attach, create new window] in screen and I value my gnome-terminal tabs. If tmux can do that, then I'd consider it reason to switch.
Check out 'byobu'. Stupid name, but it's built on screen and can use the screen commands. Byobu has F2 for new terminal tab, F3/4 to shuffle between them.
Re: Stop using tail -f (mostly)
#140Imma just gonna leave this here: http://seclists.org/fulldisclosure/2014/Nov/74