46

Why doesnt sudo /dev/null > /var/log/syslog and sudo > /var/log/syslog work, while sudo rm /var/log/syslog works?!

troylatroy
  • 1,275
  • 1
  • 11
  • 21
user259632
  • 571
  • 1
  • 4
  • 4

6 Answers6

79

truncate -s 0 /var/log/syslog

working for me on 18.04. Got it from here:

https://ubuntuforums.org/showthread.php?t=2191156

emvidi
  • 2,426
25

There are two main problems.

One problem is that /dev/null isn't a command, so running sudo /dev/null can't succeed. You need sudo [a command]. In this case, you probably want sudo cat /dev/null.

The other problem is that > separates things into a full command on the left and a file on the right, so the full command on the left is sudo cat /dev/null, and sudo's job is now done once it runs cat /dev/null.

That means that the > is running as your user, not under sudo. Your user doesn't have permission to write to /var/log/syslog, so this will fail.

You need some way to run the entire line cat /dev/null > /var/log/syslog under sudo. Well, > isn't a command or anything. It's something the shell handles, so you need to have a shell handle that redirection symbol properly. You can do that with sh's -c option: sh -c 'cat /dev/null > /var/log/syslog'.

Now that you have everything together as one command, you can have sudo run the entire thing:

sudo sh -c 'cat /dev/null > /var/log/syslog'
Chai T. Rex
  • 5,193
Elliott Frisch
  • 3,018
18

The command you are thinking of is probably

> /var/log/syslog

Nothing else is needed. In bash and other shells, the > will immediately truncate the file, emptying it. However, when you run this:

sudo /dev/null > /var/log/syslog

The system is attempting to run /dev/null as a command and you will get this error:

sudo: /dev/null: command not found

Note, however, that despite this, /var/log/syslog has actually been emptied because, as I said above, the > is enough, no command is necessary.

terdon
  • 100,812
  • no does not work,. i get the permission error using the > /var/log/syslog and as mentioned with sudo it does not work either. – Thomas Covenant Aug 15 '22 at 06:23
  • @ThomasCovenant sorry, but I have no idea what you are running. If you are running sudo > /etc/syslog, then yes, of course you will get a permission error. The > isn't being run as root, it is not part of sudo. If you run sudo -i to get a root shell and then run > /etc/syslog it will work. The > isn't a command, so it isn't affected by adding a sudo in front of it. – terdon Aug 15 '22 at 09:57
  • ah, yes it works with sudo -i – Thomas Covenant Aug 23 '22 at 08:37
3

truncate: The truncation process basically removes all the contents of the file. It does not remove the file itself, but it leaves it on the disk as a zero byte file.

Clear ALL Content of Syslog with:

sudo truncate -s 0 /var/log/syslog

Asad Ahmad
  • 31
1

Another way to do this is

sudo tee </dev/null /var/log/syslog

Or if you prefer a useless use of cat:

cat /dev/null | sudo tee /var/log/syslog
Scott Centoni
  • 111
  • 3
0

Yesterday I noticed a 14GB syslog file in my 22.04 (jammy) 6.2.0-34-generic then I landed in here. I found a different solution from the man pages and it worked. So wanted to share whoever will encounter same issue -not a problem but a preference- with the late versions of Ubuntu.

I have just edit /etc/logrotate.conf file, tweaked a couple of lines. weekly to keep the logs for 2 weeks only and size 3G to limit them under 3GB and compress.

# /etc/logrotate.conf
# see "man logrotate" for details

rotate log files weekly


weekly


keep 4 weeks worth of backlogs


rotate 2


uncomment this if you want your log files compressed


compress


size


size 3G

And the result is syslog file is divided into a couple of multiple syslog files, which have no more than 40MB, and made ~80MB total now. (amounts depend on the machine's logging history).

w3b
  • 1