named.run file deleted but data left on disk? [duplicate]
This question already has an answer here:
Find and remove large files that are open but have been deleted
3 answers
Today I had a name-server stop resolving DNS due to the /var directory being full from the named.run cache build up. I tried removing all the files using:
rm -rf name*
However, although running ls showed now files in the directory "data" running df -h still showed 100% use on /var. In the end I rebooted the machine and this resolved the problem but I am a little confused why this did not delete the files. (Obviously rebooting is not something I want to do every time even though we have failover.) Does anyone know the reason?
dns rm bind
asked Apr 25 '14 at 0:09
AliasuAliasu
41
marked as duplicate by Kusalananda, Jeff Schaller, Christopher, roaima, Olorin Feb 18 at 2:29
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
add a comment |
This question already has an answer here:
Find and remove large files that are open but have been deleted
3 answers
Today I had a name-server stop resolving DNS due to the /var directory being full from the named.run cache build up. I tried removing all the files using:
rm -rf name*
However, although running ls showed now files in the directory "data" running df -h still showed 100% use on /var. In the end I rebooted the machine and this resolved the problem but I am a little confused why this did not delete the files. (Obviously rebooting is not something I want to do every time even though we have failover.) Does anyone know the reason?
dns rm bind
asked Apr 25 '14 at 0:09
AliasuAliasu
41
marked as duplicate by Kusalananda, Jeff Schaller, Christopher, roaima, Olorin Feb 18 at 2:29
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
3
Deleted files that still have at least one open file descriptor referring to them in a running process will retain all their data, and will continue to be read from and written to by any processes that have access to the descriptor. Some workarounds are suggested in unix.stackexchange.com/a/68532/49439 . Most direct thing to do is, if you can, kill the processes that are holding the files open.
– Mark Plotnick
Apr 25 '14 at 0:20
Yep, that makes sense. Thanks Mark!
– Aliasu
Apr 25 '14 at 0:30
1
@MarkPlotnick Why don't you make that an answer?
– Hauke Laging
Apr 25 '14 at 2:02
To check before deleting a file,fuser -v <filename>will show process info currently holding a file descriptor open on a file, (or socket).
– X Tian
Apr 25 '14 at 4:14
nameddoesn't normally keepnamed.runopen; it just writes it and closes it. Maybe someone started runningless named.runand hasn't exited it. Try usingps axww | grep named.runto see if you can find it.
– Barmar
Apr 26 '14 at 6:37
add a comment |
This question already has an answer here:
Find and remove large files that are open but have been deleted
3 answers
Today I had a name-server stop resolving DNS due to the /var directory being full from the named.run cache build up. I tried removing all the files using:
rm -rf name*
However, although running ls showed now files in the directory "data" running df -h still showed 100% use on /var. In the end I rebooted the machine and this resolved the problem but I am a little confused why this did not delete the files. (Obviously rebooting is not something I want to do every time even though we have failover.) Does anyone know the reason?
dns rm bind
asked Apr 25 '14 at 0:09
AliasuAliasu
41
This question already has an answer here:
Find and remove large files that are open but have been deleted
3 answers
Today I had a name-server stop resolving DNS due to the /var directory being full from the named.run cache build up. I tried removing all the files using:
rm -rf name*
However, although running ls showed now files in the directory "data" running df -h still showed 100% use on /var. In the end I rebooted the machine and this resolved the problem but I am a little confused why this did not delete the files. (Obviously rebooting is not something I want to do every time even though we have failover.) Does anyone know the reason?
This question already has an answer here:
Find and remove large files that are open but have been deleted
3 answers
dns rm bind
dns rm bind
asked Apr 25 '14 at 0:09
AliasuAliasu
41
asked Apr 25 '14 at 0:09
AliasuAliasu
41
asked Apr 25 '14 at 0:09
AliasuAliasu
41
asked Apr 25 '14 at 0:09
AliasuAliasu
41
asked Apr 25 '14 at 0:09
AliasuAliasu
41
41
marked as duplicate by Kusalananda, Jeff Schaller, Christopher, roaima, Olorin Feb 18 at 2:29
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by Kusalananda, Jeff Schaller, Christopher, roaima, Olorin Feb 18 at 2:29
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
3
Deleted files that still have at least one open file descriptor referring to them in a running process will retain all their data, and will continue to be read from and written to by any processes that have access to the descriptor. Some workarounds are suggested in unix.stackexchange.com/a/68532/49439 . Most direct thing to do is, if you can, kill the processes that are holding the files open.
– Mark Plotnick
Apr 25 '14 at 0:20
Yep, that makes sense. Thanks Mark!
– Aliasu
Apr 25 '14 at 0:30
1
@MarkPlotnick Why don't you make that an answer?
– Hauke Laging
Apr 25 '14 at 2:02
To check before deleting a file,fuser -v <filename>will show process info currently holding a file descriptor open on a file, (or socket).
– X Tian
Apr 25 '14 at 4:14
nameddoesn't normally keepnamed.runopen; it just writes it and closes it. Maybe someone started runningless named.runand hasn't exited it. Try usingps axww | grep named.runto see if you can find it.
– Barmar
Apr 26 '14 at 6:37
add a comment |
3
Deleted files that still have at least one open file descriptor referring to them in a running process will retain all their data, and will continue to be read from and written to by any processes that have access to the descriptor. Some workarounds are suggested in unix.stackexchange.com/a/68532/49439 . Most direct thing to do is, if you can, kill the processes that are holding the files open.
– Mark Plotnick
Apr 25 '14 at 0:20
Yep, that makes sense. Thanks Mark!
– Aliasu
Apr 25 '14 at 0:30
1
@MarkPlotnick Why don't you make that an answer?
– Hauke Laging
Apr 25 '14 at 2:02
To check before deleting a file,fuser -v <filename>will show process info currently holding a file descriptor open on a file, (or socket).
– X Tian
Apr 25 '14 at 4:14
nameddoesn't normally keepnamed.runopen; it just writes it and closes it. Maybe someone started runningless named.runand hasn't exited it. Try usingps axww | grep named.runto see if you can find it.
– Barmar
Apr 26 '14 at 6:37
3
3
Deleted files that still have at least one open file descriptor referring to them in a running process will retain all their data, and will continue to be read from and written to by any processes that have access to the descriptor. Some workarounds are suggested in unix.stackexchange.com/a/68532/49439 . Most direct thing to do is, if you can, kill the processes that are holding the files open.
– Mark Plotnick
Apr 25 '14 at 0:20
Deleted files that still have at least one open file descriptor referring to them in a running process will retain all their data, and will continue to be read from and written to by any processes that have access to the descriptor. Some workarounds are suggested in unix.stackexchange.com/a/68532/49439 . Most direct thing to do is, if you can, kill the processes that are holding the files open.
– Mark Plotnick
Apr 25 '14 at 0:20
Yep, that makes sense. Thanks Mark!
– Aliasu
Apr 25 '14 at 0:30
Yep, that makes sense. Thanks Mark!
– Aliasu
Apr 25 '14 at 0:30
1
1
@MarkPlotnick Why don't you make that an answer?
– Hauke Laging
Apr 25 '14 at 2:02
@MarkPlotnick Why don't you make that an answer?
– Hauke Laging
Apr 25 '14 at 2:02
To check before deleting a file,
fuser -v <filename> will show process info currently holding a file descriptor open on a file, (or socket).– X Tian
Apr 25 '14 at 4:14
To check before deleting a file,
fuser -v <filename> will show process info currently holding a file descriptor open on a file, (or socket).– X Tian
Apr 25 '14 at 4:14
named doesn't normally keep named.run open; it just writes it and closes it. Maybe someone started running less named.run and hasn't exited it. Try using ps axww | grep named.run to see if you can find it.– Barmar
Apr 26 '14 at 6:37
named doesn't normally keep named.run open; it just writes it and closes it. Maybe someone started running less named.run and hasn't exited it. Try using ps axww | grep named.run to see if you can find it.– Barmar
Apr 26 '14 at 6:37
add a comment |
2 Answers
2
active
oldest
votes
Check the output of:
find /proc/*/fd -ls | grep '(deleted)'
If you find your files listed here, kill the process which has an open file descriptor (or file handle). That should do the trick!
answered Jul 13 '15 at 10:49
miragemirage
1013
add a comment |
Restarting named service or doing rndc reload should solve that problem.
answered Feb 16 at 21:21
e_tolue_tolu
1
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Check the output of:
find /proc/*/fd -ls | grep '(deleted)'
If you find your files listed here, kill the process which has an open file descriptor (or file handle). That should do the trick!
answered Jul 13 '15 at 10:49
miragemirage
1013
add a comment |
Check the output of:
find /proc/*/fd -ls | grep '(deleted)'
If you find your files listed here, kill the process which has an open file descriptor (or file handle). That should do the trick!
answered Jul 13 '15 at 10:49
miragemirage
1013
add a comment |
Check the output of:
find /proc/*/fd -ls | grep '(deleted)'
If you find your files listed here, kill the process which has an open file descriptor (or file handle). That should do the trick!
answered Jul 13 '15 at 10:49
miragemirage
1013
Check the output of:
find /proc/*/fd -ls | grep '(deleted)'
If you find your files listed here, kill the process which has an open file descriptor (or file handle). That should do the trick!
answered Jul 13 '15 at 10:49
miragemirage
1013
answered Jul 13 '15 at 10:49
miragemirage
1013
answered Jul 13 '15 at 10:49
miragemirage
1013
answered Jul 13 '15 at 10:49
miragemirage
1013
1013
add a comment |
add a comment |
Restarting named service or doing rndc reload should solve that problem.
answered Feb 16 at 21:21
e_tolue_tolu
1
add a comment |
Restarting named service or doing rndc reload should solve that problem.
answered Feb 16 at 21:21
e_tolue_tolu
1
add a comment |
Restarting named service or doing rndc reload should solve that problem.
answered Feb 16 at 21:21
e_tolue_tolu
1
Restarting named service or doing rndc reload should solve that problem.
answered Feb 16 at 21:21
e_tolue_tolu
1
answered Feb 16 at 21:21
e_tolue_tolu
1
answered Feb 16 at 21:21
e_tolue_tolu
1
answered Feb 16 at 21:21
e_tolue_tolu
1
1
add a comment |
add a comment |
3
Deleted files that still have at least one open file descriptor referring to them in a running process will retain all their data, and will continue to be read from and written to by any processes that have access to the descriptor. Some workarounds are suggested in unix.stackexchange.com/a/68532/49439 . Most direct thing to do is, if you can, kill the processes that are holding the files open.
– Mark Plotnick
Apr 25 '14 at 0:20
Yep, that makes sense. Thanks Mark!
– Aliasu
Apr 25 '14 at 0:30
1
@MarkPlotnick Why don't you make that an answer?
– Hauke Laging
Apr 25 '14 at 2:02
To check before deleting a file,
fuser -v <filename>will show process info currently holding a file descriptor open on a file, (or socket).– X Tian
Apr 25 '14 at 4:14
nameddoesn't normally keepnamed.runopen; it just writes it and closes it. Maybe someone started runningless named.runand hasn't exited it. Try usingps axww | grep named.runto see if you can find it.– Barmar
Apr 26 '14 at 6:37