- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: kmemdaemon - Can I kill it?
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
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
Community
Resources
Forums
Blogs
- 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
05-11-2017 11:00 AM
05-11-2017 11:00 AM
Hello,
I noticed the following process and using high CPU. Can I kill it?
(root)> ps -ef| grep kmemdaemon
root 6 0 0 Apr 20 ? 11895:53 kmemdaemon
root 10329 18026 0 13:37:23 pts/4 0:00 grep kmemdaemon
(root) >
Thanks
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-11-2017 12:36 PM
05-11-2017 12:36 PM
Re: kmemdaemon - Can I kill it?
Any help, really appreciate.
Also, fcachedaemon and midaemon. Highly used CPU, so want to kill all those 3 processes. Is that bad or no?
Thank you,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-11-2017 12:53 PM
05-11-2017 12:53 PM
Re: kmemdaemon - Can I kill it?
Are those process currently using large amounts of CPU or have they just accumulated a lot of CPU time?
Does 'top' show those processes as using a lot of CPU?
How long has your system been up without a reboot? What does 'uptime' show?
The kmemdaemon and fcachedaemon are system processes. You should NOT kill those. If you do there is a risk that you may crash your system.
The midaemon gather performace data. You can stop it by running 'midaemon -T'.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-11-2017 12:57 PM
05-11-2017 12:57 PM
Re: kmemdaemon - Can I kill it?
(root) @/> ps -ef| grep fcachedaemon
root 124 0 0 Apr 20 ? 19560:03 fcachedaemon
root 29532 18026 0 15:55:14 pts/4 0:00 grep fcachedaemon
(root)@/> ps -ef| grep kmemdaemon
root 6 0 0 Apr 20 ? 11901:27 kmemdaemon
root 29534 18026 0 15:55:17 pts/4 0:00 grep kmemdaemon
(root) @/> ps -ef| grep midaemon
root 3665 1 0 Apr 20 ? 23095:33 /opt/perf/bin/midaemon
root 29552 18026 0 15:55:22 pts/4 0:00 grep midaemon
(root) omhdwp1@/>
Server has been up for 368 days and we can't reboot now. The reason I asked to kill those were, I noticed the date of April 20 and from April 21st few of our jobs are failing. So wondering if that has to do with that or not.
Please let me know.
Thank you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-11-2017 01:12 PM
05-11-2017 01:12 PM
Re: kmemdaemon - Can I kill it?
It's possible that the Apr 20 date is actually April 20, 2016 since the system has been up for more than a year.
"...and from April 21st few of our jobs are failing." How are they failing? What do logs files say? What errors are given?
It's impossible to say whether or not those are the culprit without a lot more information.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-11-2017 01:15 PM
05-11-2017 01:15 PM
Re: kmemdaemon - Can I kill it?
True that is what I was thinking too. But the cp and gzip are failing. And when they run manually it is running fine. So driving crazy what could be the reason. From april 21st they started failing to cp from one directory to archive directory and sometimes gunzip fails. This is happening at 3am but runs fine when we run the job manually at 7am. Wondering what could be?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-11-2017 01:36 PM
05-11-2017 01:36 PM
Re: kmemdaemon - Can I kill it?
What does "failing" mean? Are there any errors anywhere?
Are you running short of memory? What does 'swapinfo -tam' show?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-11-2017 01:47 PM
05-11-2017 01:47 PM
Re: kmemdaemon - Can I kill it?
Failing means, in the script i get no such file or directory, when i listed prior to the copy it lists the file but it doesn't copy from one directory to the other on the same server. and later it uncompresses and sometimes that is failing, when cp works. so wired....trying to find what might be the reason.
(root) @/> swapinfo -tam
Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 8192 0 8192 0% 0 - 1 /dev/vg00/lvol2
dev 101312 6273 95039 6% 0 - 0 /dev/vgswap01/lvswap01
reserve - 58395 -58395
memory 93332 18341 74991 20%
total 202836 83009 119827 41% - 0 -
(root) @/>
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-11-2017 08:53 PM - edited 05-11-2017 08:54 PM
05-11-2017 08:53 PM - edited 05-11-2017 08:54 PM
Re: kmemdaemon - Can I kill it?
The processes that are failing are not failing due to an HP-UX issue. "No such file or directory" is a somewhat ambiguous error in that ir doesn't tell you what component of cp actually failed. Was it the source or was it the destination? Are you using relative pathnames (ie, paths that don't start with "/"). You mentioned remote so are you having problems with NFS mounts?
Similarly, what are the gzip errors? Again, actual error messages would help. Note that commands that seem to work when running manually are likely failing due to the environment of the script.
The errors you are seeing need more details. First, make sure that you never use relative or partial pathnames. Then add debug lines to your script to verify both the source pathname and also the destination path actually exist before the cp or gzip commands are run. When your script runs the cp or gzip commands, one of the paths doesn't exist. Since it is intermittant, the sources and destinations may come from other files or runtime parameters or other sources.
Bill Hassell, sysadmin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-11-2017 11:46 PM
05-11-2017 11:46 PM
Re: kmemdaemon - Can I kill it?
> [...] First, make sure that you never use relative or partial
> pathnames. [...]
Nonsense. Relative paths work exactly as well as absolute paths,
_if_ your current working directory is appropriate.
> The errors you are seeing need more details.
He means that we need a better description of the problem.
As usual, showing actual commands with their actual output (error
messages) can be more helpful than vague descriptions or
interpretations.
> Failing means, [...] and sometimes that is failing, [...]
Not a useful problem description. It does not say what you did. It
does not say what happened when you did it.
> [...] in the script i get no such file or directory, [...]
What was the actual command which failed?
> [...] it doesn't copy from one directory to the other on the same
> server. [...]
What's the command, and what's the error message in that case?
It's difficult for anyone else to say what you're doing wrong, when
you're the only one who knows what you're doing.