"tail -f" doesn't work

For some reason I can’t get tail -f to work. It simply doesn’t update. Other similar programs have the same problem. I’ve tried lnav and multitail and neither can sense the files updating.
It doesn’t even work for a local file in my home folder that I manually change. I’m at a complete loss why this is. Any help would be appreciated.

You might be mistaken on how tail -f <filename> actually works.

What, exactly, are you trying to do/accomplish?

1 Like

I’ve been using tail -f for many years, so I think I have an idea of what is supposed to happen. I oculd be wrong ofcourse, but I’m comparing it how it works for my other linux systems.

I think the problem is that inotify is not registering events in such a way that tail -f can see it.

If I use inotifywait to see what is going wrong I can see that MODIFY events are created by adding a line to a file in nano, but in mousepad it creates a DELETE_SELF event at which point it stops following. What I don’t understand is why tail can follow a file even if I edit with mousepad in my other linux laptop. This file editing is just an example of course. The real usercase is following a logfile on a mounted sambashare. This too works for my other laptop (the very same file) so I can’t see why it would be different when using manjaro (or maybe it’s HW related, I don’t know).

Isn’t that something you can normally do?

Hi, @Premi ,
Could you please run the following command on the terminal?
man tail

You could read in the first line of the DESCRIPTION section at the beginning the following text:
Print the last 10 lines of each FILE to standard output

Then, @merlock is right telling you that you have to provide the FILE.

For example,
tail -f /var/log/Xorg.0.log

Hope this help, regards

I’ve been using linux for over 20 years, and have never encountered a use-case for using tail to try and observe file editing ‘on the fly’ (it doesn’t work in vim, either).

-f, --follow[={name|descriptor}]
	      output appended data as the file grows;

	      an absent option argument means 'descriptor'

Even if you add lines in an editor, I don’t think it’s considered a direct appending.

Test it yourself:

  1. Create a throw-away directory mkdir ~/temp

  2. Open 2 terminals in that directory.

  3. In one terminal, run touch test

  4. In the other terminal, tail -f test

  5. In the first terminal, run these in sequence, and watch the tail output:

  • echo "hello" > test

  • echo "there" >> test

  • echo "forgetaboutit" > test

Your output should be similar:

tail -f test
hello  
there
tail: test: file truncated
forgetaboutit

As long as the share is mounted, and you have proper permissions, you should be able to do that (and that, IMO is what tail -f is really for.

Naturally, I was always tailing a file. The tail part always worked it was the -f (follow) part that didn’t work. It just didn’t update for changes.

I was just trying to troubleshoot the issue (in a clumsy manner, I grant you).

I haven’t determined why my troubleshooting example was working on my other laptop, maybe it is just using a different implementation of tail but this comparison lead my assumptions astray a bit.

What I know is that my samba share doesn’t yield any ionotify events when the changes are generated on the host side. I mounted this share with systemd, and I can see it includes alot of extra arguments that I didn’t specify in fstab. When I instead mounted the same samba share manually I WAS able to follow the file with tail. So I think it has something to do with how the samba share was mounted. Maybe it was the ‘nounix’ option that systemd added. I’ve resorted to mount the same share with sshfs instead and now it works as it should.

I still don’t why -follow doesn’t work for the samba share, but I found that sshfs is working very well (better than the samba even when it is working) so it’s not something I’m going to spend more time on. Thanks for your help anyway.