kmemdaemon - Can I kill it?

[rescuehp17]

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

[rescuehp17]

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,

[Patrick Wallek]

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'.

[rescuehp17]

(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.

[Patrick Wallek]

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.

[rescuehp17]

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?

[Patrick Wallek]

What does "failing" mean?  Are there any errors anywhere?

Are you running short of memory?  What does 'swapinfo -tam' show?

[rescuehp17]

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) @/>

[Bill Hassell]

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.

[Steven Schweda]

> [...] 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.