File is corrupt linux

unix file is corrupted [closed]

Questions describing a problem that can’t be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers.

I discovered that one of my logs consumes lots of space which comes from a running process. I wanted to clean this file, so I can run logadm to rotate it after. but I don’t know how

# >MyLog_nohup.out # ls -lLh MyLog_nohup.out -rw-r-lr-- 1 user group 72G Jul 30 07:26 MyLog_nohup.out # du -sh MyLog_nohup.out 480K MyLog_nohup.out 

Even after freeing it, still consumes 72G, and running more on it, just showing blank lines.. How can I fix that? I can’t afford restarting the process. But I wanted to use logadm to rotate this log file, is this possible? I tried, but it keeps coping blank lines an infinite loop. same as when I do more on this file. Is there any other way to fix this? For logrotate, there is copytruncate option that deals with the open file, but I can’t use it while the file has these blank lines as it runs in a loop. I still don’t understand why I can not view/more/head this file!

What really would you lose if you kill that process? It is buggy beyond the reasonable, so why do you want to keep it running? It is useless!

What are you really risking? Would you be killed (e.g. shot) or go to jail if you lose your process (I don’t think so)? Why are you waiting till the disk is entirely fulled by useless log content?

As the last resort, you might give a try to attaching the process by gdb and close() the file descriptor in question. See this answer for details. I can never guarantee success!

2 Answers 2

Your file is not corrupted; On Linux and POSIX systems, as long as a running process has an opened file descriptor to some file that it is writing, it will be able to continue writing it, even if you remove or rename that file (because a file descriptor is related to an i-node, not to a file name). in particular logrotate or logadm -or any sequence of external commands- won’t do anything useful about the disk space.

I am assuming you are on Linux.

If your process has pid 1234, you could look into /proc/1234/ in particular list the /proc/1234/fd/ directory. Read proc(5).

You probably should stop the offending process (using kill -TERM then kill -QUIT then at last kill -KILL ; see signal(7) & kill(1)), then remove the file, and at last correct and/or configure your program to do some more useful logs, and start it again.

You probably have lost all the computation done by your program. So better stop it ASAP, improve it (perhaps you want some application checkpointing, or persistence, or add some way to have it close, then rename, and then re-open the log file), and restart an improved version of your program.

You should read Advanced Linux Programming. You probably have several bugs in your program (perhaps related to logging). You might use strace(1) to understand the syscalls done by your process, and you could use syslog(3) inside your (improved) program.

Very probably, you have a design bug in your program. So better stop it now, think, improve it, and start again. Waiting for the disk to be entirely filled won’t help you (and it would make the matter worse).

For future testing purposes, you might consider setting some disk quotas and or some resource limits (e.g. setrlimit(2), and bash ulimit builtin).

In the future, always design your program to be able to afford restarting the process. Not being able to afford that is always a huge mistake (in particular, you need some backup strategy, and you need some revision control on your source code; I recommend git for that).

Источник

How do I fix corrupt files in Linux?

Most common causes of file system corruption are due to improper shutdown or startup procedures, hardware failures, or NFS write errors. Shutdown should be done through one of the system shutdown commands; these sync the file system first. Software errors in the kernel can also cause file system corruption.

How do you check if a file is corrupted in Linux?

No, there aren’t any general solutions. The only way to check if a file is corrupt is to try and read it; only software which knows how to read that particular format can do that.

Why we use fsck in Linux?

The fsck (File System Consistency Check) Linux utility checks filesystems for errors or outstanding issues. The tool is used to fix potential errors and generate reports. This utility comes by default with Linux distributions. No specific steps or an installation procedure is required to use fsck.

How do you test if a file is corrupted?

Look at the file size. Right-click on the file and choose “Properties.” You will see the file size in the Properties. Compare this to another version of the file or a similar file if you have one. If you have another copy of the file and the file you have is smaller, then it may be corrupt.

What to do if you have a corrupted file on your computer?

In the case of corrupted system files (from an unexpected shutdown, bad update, or malware), you can always try something like Windows’ built in System File Checker. It scans your system for corrupted system files, and then replaces them with originals. Before you do that, though, it’s best to try fixing the cause of the problem.

Is the Linux file system corrupt or inconsistant?

Though any linux compatible modern file systems are quite versatile and resilient, there are trade offs between performance and consistency and they can depending on the situation be found inconsistant or corrupted. And further more, when you do fsck or xfs_repair, the safest way is to do so on an UNmounted file system.

How to detect a corrupted file in Unix?

1) cat ham.log returns: ham.log: Corrupted file system detected. I have never heard of behavior like that. What version of unix are you using? I would try exactly what you did from the command line in a script. I assume that you are using ksh as your login shell. Since the cat command is detecting the problem, go with that.

Why do I have errors in my Linux filesystem?

Filesystem might gets corrupted due to power failure, hardware failure, unclean shutdown etc. You might see errors like “touch: cannot touch file: Read-only file system” if there is file system errors on your linux server.

Источник

How to repair a file system corruption?

The system boots and works normally. Is it possible to repair this fully, and what is the proper way?

If this happens after a brutal shutdown, no worries, it s probably tmp files. If it happened during use, then you should first backup everything important (on 2 separate supports, in case one fails)

3 Answers 3

You can instruct the filesystem to perform an immediate fsck upon being mounted like so:

Method #1: Using /forcefsck

You can usually schedule a check at the next reboot like so:

$ sudo touch /forcefsck $ sudo reboot 

Method #2: Using shutdown

You can also tell the shutdown command to do so as well, via the -F switch:

NOTE: The first method is the most universal way to achieve this!

Method #3: Using tune2fs

You can also make use of tune2fs , which can set the parameters on the filesystem itself to force a check the next time a mount is attempted.

$ sudo tune2fs -l /dev/sda1 Mount count: 3 Maximum mount count: 25 

So you have to place the «Mount count» higher than 25 with the following command:

$ sudo tune2fs -C 26 /dev/sda1 

Check the value changed with tune2fs -l and then reboot!

NOTE: Of the 3 options I’d use tune2fs given it can deal with force checking any filesystem whether it’s the primary’s ( / ) or some other.

Additional notes

You’ll typically see the «Maximum mount count:» and «check interval:» parameters associated with a partition that’s been formatted as ext2/3/4. Often times they’re configured like so:

$ tune2fs -l /dev/sda5 | grep -E "Mount count|Maximum mount|interval" Mount count: 178 Maximum mount count: -1 Check interval: 0 () 

When the parameters are set this way, the device will never perform an fsck during mounting. This is fairly typical with most distros.

There are 2 forces that drive a check. Either number of mounts or an elapse time. The «Check interval» is the time based one. You can say every 2 weeks to that argument, 2w. See the tune2fs man page for more info.

NOTE: Also make sure to understand that tune2fs is a filesystem command, not a device command. So it doesn’t work with just any old device, /dev/sda , unless there’s an ext2/3/4 filesystem there, the command tune2fs is meaningless, it has to be used against a partition that’s been formatted with one of those types of filessystems.

References

Источник