Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop using tail -f (mostly)

brianstorti.com

Post reply on HN
Print view View original

71–80 of 211 posts

Re: Stop using tail -f (mostly)

#71

Post by [deleted] »

fweespeech wrote: post #19
nothrabannosir wrote: post #9

Even when you don't want less +F, a good alternative to tail -f is tail -F. It survives log rotation, and the file being temporarily inaccessible: --retry keep trying to open a file even if it is inaccessible when tail starts or if it becomes inaccessible later; useful when follow- ing by name, i.e., with --follow=name -F same as --follow=name --retry

Yeah, tail -F is the way to go imo. Also, if you are using a proper ssh client, opening a second ssh connection to manage the reacting to the log files is habit for me at this point. The only time I'm using tail -F is after a new configuration deployment. Otherwise, I'm looking at archival data in ELK.

[deleted]

Re: Stop using tail -f (mostly)

#72

Post by pjungwir »

bch wrote: post #31
evincarofautumn wrote: post #21

Earlier quoted context omitted.

With less, you can use m to mark the current position and ' to go to a marked position. h will show you lots of useful help.

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) * ...

Another less-vs-vi question:

As a junior programmer I got chewed out by my IT department because I was examining a (production) log file in vi. The sysadmin told me I should use less (actually more---this was on Solaris in ~2001). To this day I only read log files with less, but I've never figured out his objection. Negatives to using vi I can imagine are:

- I might write to the log file. That seems like a real worry, although I could also say `vi -R` to prevent it.

- Starving the production system of memory. I'm pretty sure he expressed this concern. Any insight into whether it is legit? Is less actually any better?

Obviously you really should have a log shipping & aggregation service so you can read logs offline, etc, but not every project is large enough for that, nor every org organized enough. So for the sake of argument my premise is, "Assuming you want to read a log on production . . ."

Re: Stop using tail -f (mostly)

#73

Post by vbezhenar »

pjungwir wrote: post #72
bch wrote: post #31

Earlier 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) * ...

Another less-vs-vi question: As a junior programmer I got chewed out by my IT department because I was examining a (production) log file in vi. The sysadmin told me I should use less (actually more---this was on Solaris in ~2001). To this day I only read log files with less, but I've never figured out his objection. Negatives to using vi I can imagine are: - I might write to the log file. That seems like a real worry…

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.

Re: Stop using tail -f (mostly)

#74

Post by dexxtreme »

pjungwir wrote: post #72
bch wrote: post #31

Earlier 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) * ...

Another less-vs-vi question: As a junior programmer I got chewed out by my IT department because I was examining a (production) log file in vi. The sysadmin told me I should use less (actually more---this was on Solaris in ~2001). To this day I only read log files with less, but I've never figured out his objection. Negatives to using vi I can imagine are: - I might write to the log file. That seems like a real worry…

If I'm logging into a server later to resolve an issue, one thing I will probably check is the command history. If you open a file with "vi", how do I know that you only looked at it, and did not make any changes to it? When I see "less" in the command history, I know for certain that it was a read-only operation.

Re: Stop using tail -f (mostly)

#76

Post by yellowapple »

Filligree wrote: post #33
stonogo wrote: post #18

Be 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.

Do you mean creating a new window every time you attach to an existing session? Or do you mean that each of those actions ("attach" and "create new window") should be atomic?

Re: Stop using tail -f (mostly)

#77

Post by freehunter »

pjungwir wrote: post #72
bch wrote: post #31

Earlier 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) * ...

Another less-vs-vi question: As a junior programmer I got chewed out by my IT department because I was examining a (production) log file in vi. The sysadmin told me I should use less (actually more---this was on Solaris in ~2001). To this day I only read log files with less, but I've never figured out his objection. Negatives to using vi I can imagine are: - I might write to the log file. That seems like a real worry…

I don't know his exact reasoning, but the biggest thing I can think of you already touched upon: there's more of a danger that you can write to a file accidentally with vi vs with less.

Beyond that, I would probably correct a junior employee as well. Even if there's nothing wrong with it, it's not the right tool for the job. When I first started I got 'yelled' at for checking to see if a machine was on the network using tracert instead of ping. It works, but it's not the right tool for the job.

Re: Stop using tail -f (mostly)

#78

Post by cstoner »

pjungwir wrote: post #72
bch wrote: post #31

Earlier 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) * ...

Another less-vs-vi question: As a junior programmer I got chewed out by my IT department because I was examining a (production) log file in vi. The sysadmin told me I should use less (actually more---this was on Solaris in ~2001). To this day I only read log files with less, but I've never figured out his objection. Negatives to using vi I can imagine are: - I might write to the log file. That seems like a real worry…

It's a good practice for sure, but your sysadmin was probably a little over-hash.

I'm generally in the habit of using `view` to do read-only vim. `less` works as well.

Re: Stop using tail -f (mostly)

#79

Post by beernutz »

sciurus wrote: post #57

If you're looking at log files, a tool I've started to play with is http://lnav.org/ = In Your Terminal = Many logging tools, like Splunk, provide great features but are optimized for large-scale deployments. They require installing and configuring servers before they can be effectively used. There is still a need for a robust log file analyzer for the terminal. = Easy to Use = Just point lnav to a directory and it w…

That looks very nice! Thanks for the info. 8)

Re: Stop using tail -f (mostly)

#80

Post by nodata »

pjungwir wrote: post #72
bch wrote: post #31

Earlier 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) * ...

Another less-vs-vi question: As a junior programmer I got chewed out by my IT department because I was examining a (production) log file in vi. The sysadmin told me I should use less (actually more---this was on Solaris in ~2001). To this day I only read log files with less, but I've never figured out his objection. Negatives to using vi I can imagine are: - I might write to the log file. That seems like a real worry…

Yes, but cpu is normally the problem. vim is very inefficient with long lines, combine that with all of vim's features (syntax highlighting, etc.) and you have the potential to make a problem worse.
Post reply on HN