Ja alleen moet je daarna wel de logdaemon herstarten, de ingewikkelde uitleg waarom zal ik je besparen, maar anders helpt 't niet.
Makkelijkste en domste methode is: file leegmaken, rebooten. Slimmere methode: killall sys[k]logd, beste methode: het opstart-script dat redhat gebruikt om de syslogger te starten opzoeken en dat aanroepen met 'restart' als argument (ws. iets van /etc/init.d/syslogd restart intypen ofzo).
Edit: Owja, niet eens gezien. De files met .1 etc. erachter zijn archives dus die kunnen sowieso pleitte ja. Hoef je ook de logdaemon niet voor te herstarten dus
offtopic:
Stiekem toch de ingewikkelde uitleg:
Als je in Linux een file wist, wordt niet de feitelijke data gewist maar alleen de verwijzing er naartoe. Als er geen links meer naar een file zijn, is de data vanzelf 'verdwenen' omdat het niet meer te openen is! Echter, processen die een bestand voor het deleten al geopend hadden kunnen er nog gewoon uit lezen/in schrijven, totdat ook zij de file sluiten. Op dat moment verdwijnt de data gewoon in het niets, omdat er gewoon geen manier is om nog uit te vinden waar de data is (nou ja, niet zonder undelete tools anyway
).
Dat is wat er gebeurt als je de logdaemon niet herstart - de ruimte is gewoon nog 'in gebruik' tot het moment dat het laatste proces de file ook daadwerkelijk sluit - deleten (=feitelijk: een link naar de file verwijderen) is niet genoeg. Bij het herstarten van de logdaemon sluit deze de file, en zal daarna gedwongen worden een nieuwe te beginnen omdat de oude pleitte is.
Hopelijk draagt deze uitleg iets bij aan het begrip van Linux in het algemeen
P.S. Dit is dus ook de reden waarom je in Linux
wel een in gebruik zijnde file kunt deleten en al dat soort grappen meer waaraan je je in Windows altijd kapot ergert omdat het niet gewoon werkt
/u/26742/000000751.png?f=community)