- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - Linux
- >
- Re: "ps -aef" does not show pdflush process
Operating System - Linux
1748166
Members
3832
Online
108758
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Go to solution
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-15-2009 01:25 AM
тАО12-15-2009 01:25 AM
"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
# 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
Solved! Go to Solution.
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-15-2009 05:57 AM
тАО12-15-2009 05:57 AM
Solution
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
----------
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
MK
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-16-2009 02:22 AM
тАО12-16-2009 02:22 AM
Re: "ps -aef" does not show pdflush process
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-16-2009 04:13 AM
тАО12-16-2009 04:13 AM
Re: "ps -aef" does not show pdflush process
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
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/
/proc/
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
MK
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP