topic Re: "ps -aef" does not show pdflush process in Operating System - Linux

"ps -aef" does not show pdflush process

monu_1 — Tue, 15 Dec 2009 09:25:51 GMT

"ps -aef" doesn't show pdflush as running, while further shows it's running by either the top command or inspecting the /proc filesystem.

# cat /proc/sys/vm/nr_pdflush_threads
2

Questions:
1. Why doesn't "ps -aef" show pdflush as running where as "top" and /proc shows the same.

2. How exactly is pdflush disabled?

3. What are the consequences of pdflush being disabled?

mks

Re: "ps -aef" does not show pdflush process

Matti_Kurkela — Tue, 15 Dec 2009 13:57:40 GMT

Linux kernel documentation tells this about nr_pdflush_threads sysctl parameter:
----------
nr_pdflush_threads

The current number of pdflush threads. This value is read-only.
The value changes according to the number of dirty pages in the system.

When necessary, additional pdflush threads are created, one per second, up to
nr_pdflush_threads_max.
-----------

In other words: this is not a tunable, just an indicator. The kernel will automatically start pdflush threads as necessary, and when they no longer have any work to do for a while, they will simply die.

If I'm reading the source code correctly, one pdflush thread will die away when it has spent 1 second sleeping with no work.

1.) Please show the exact commands you're using and their results. On my system, I can see the pdflush processes just fine:

$ ps -aef |grep pdflush
root 206 2 0 Dec06 ? 00:00:00 [pdflush]
root 207 2 0 Dec06 ? 00:00:00 [pdflush]
mkurkela 27959 27915 0 15:04 pts/0 00:00:00 grep pdflush

2.)
You can't disable it completely, but you can tune its behaviour. See Documentation/sysctl/vm.txt in the kernel source package (in many Linux distributions, this may be a separate kernel-doc RPM).

In kernel 2.6.32, pdflush seems to be gone, replaced by something else.

3.)
Pdflush's job is to push write-cached data from the OS's page cache to disk, whenever the cached data becomes older than some threshold value or when memory is needed for more important purposes than caching.

If pdflush could be completely disabled, some often-used data could be held in the page cache indefinitely, accumulating a large number of changes. If the system then lost power, these changes would be lost. You would then end up with a very corrupted file.

MK

Re: "ps -aef" does not show pdflush process

monu_1 — Wed, 16 Dec 2009 10:22:13 GMT

Thanks for response MK.

Here is output.

root@localhost:~# top -b | grep pdflush
174 root 20 0 0 0 0 S 0.0 0.0 0:00.00 pdflush
175 root 15 0 0 0 0 S 0.0 0.0 0:00.15 pdflush
174 root 20 0 0 0 0 S 0.0 0.0 0:00.00 pdflush
175 root 15 0 0 0 0 S 0.0 0.0 0:00.15 pdflush
root@localhost:~# ps -eaf | grep pdflush
root 21910 16308 0 05:13 pts/0 00:00:00 grep pdflush

root@localhost:~# ps aux | grep pdflush
root 22097 0.0 0.0 3660 500 pts/0 S+ 05:13 0:00 grep pdflush

root@localhost:~# ps -C pdflush
PID TTY TIME CMD
174 ? 00:00:00 pdflush
175 ? 00:00:00 pdflush

root@localhost:~# cat /proc/sys/vm/nr_pdflush_threads
2
root@localhost:~# cat /proc/sys/vm/dirty_ratio
10

We can see this process in top and proc but not ps. Please adbice.

Re: "ps -aef" does not show pdflush process

Matti_Kurkela — Wed, 16 Dec 2009 12:13:19 GMT

That's strange. The ps command should definitely not omit the pdflush processes like that. The "ps -C pdflush" command still shows them, so it looks like your ps command does some filtering by default.

Can you find any other discrepancies between the ps output and the /proc file system? If you find other relatively long-lived processes that are visible in /proc but not in "ps" output, examine them very carefully using the facilities available in /proc.

For example: /proc//exe is a symbolic link to the executable that is currently run by the process. You might use the "strings" command to take a peek inside the executable and see if you can identify it.

/proc//cwd is a symbolic link to the current working directory of that process: you can use a command like "cd /proc//cwd" to enter the process's working directory and examine any files you may find there.

Is the ps command you're running the standard version, or a customized one? Use "which ps" to see the full pathname of the ps command, then use the package management tools of your Linux distribution to verify that the command binary is what it's supposed to be.

For example, "which ps" probably reports /bin/ps. If it reports something different, there may be a custom PATH or shell alias that makes the ps command behave differently - disable/override them temporarily and see if it helps.

To verify a file with the RPM package management tools:
rpm --verify --file /bin/ps

If it displays nothing, the file matches what the package management system knows about it.

Maybe an intruder has gained access to your system and installed a "rootkit" to hide his/her processes on the system. This hiding mechanism may be interfering with the ps command, causing it to display incomplete results in some cases.

Rootkits are usually built to resist detection and removal and to make re-intrusion easier.

If your system has been compromised in this way, the recommended practice that you backup all data and configuration files, and then re-install the system from scratch using known good installation media. Of course you should also install all the applicable security updates before connecting the system to the network again.

Don't overwrite any old backups if your system has been compromised: you may need them to verify that the intruder has not tampered with your application data.

Never restore any binaries from a compromised system: they may have been changed by the intruder. Compare all configuration files to default versions and verify that all changes are legitimate before restoring a configuration file to a re-installed system.

MK