Sponsored Content
Operating Systems HP-UX How to clear defunct processes?? Post 302753837 by Corona688 on Wednesday 9th of January 2013 12:22:39 PM
Old 01-09-2013
It's not the system that's letting them accumulate, it's whatever program creating them that is. They still belong to a living process, one which hasn't called wait() for them. That's a bug.

If you restart that daemon, causing it to quit and reload, those zombie processes will default their ownership back to INIT, which will handle them properly.
 

10 More Discussions You Might Find Interesting

1. UNIX for Dummies Questions & Answers

<DEFUNCT> Processes

When I ps -ef I see about 3 or 4 <DEFUNCT> things - what are these, and what causes them? Are they a concern? How can I fix them? Thanks, Michael (4 Replies)
Discussion started by: cuppjr
4 Replies

2. Solaris

how do I kill defunct processes?

mqm 17700 16815 0 0:00 <defunct> kill -9 does not work, even as root (10 Replies)
Discussion started by: csaunders
10 Replies

3. UNIX for Dummies Questions & Answers

Question about defunct processes

Hey guys/gals. I am new to the site and fairly new to Unix/Linux. I have a master netbackup server (solaris) that I get pinged on occasionally regarding defunct processes. (Usually over 50 or so of them.) I know what a defunct process is, but what is it a product of? Just plain sloppy code? (From... (1 Reply)
Discussion started by: EMCSANMAN
1 Replies

4. UNIX for Dummies Questions & Answers

whats the difference between zombie orpha and defunct processes

can some one please explain zombie orphan defunct and how they r related (3 Replies)
Discussion started by: pbsrinivas
3 Replies

5. AIX

Defunct Processes

Hi, Can any one help me to get rid of defunct process on UNIX IBM AIX box. These processes started when the system was rebooted almost after 1 1/2 years. Once one defunct process is created then all the user ids get infected and in turn creates numerous defunct processes. We have tried... (6 Replies)
Discussion started by: trokia88
6 Replies

6. Programming

defunct vs running

hello everybody! Is there any way to identify if a process is defunct or if it is still running? (in C). for example: by using a signal such as SIGCHLD? thanx in advance (1 Reply)
Discussion started by: nicos
1 Replies

7. Shell Programming and Scripting

Abnormal behaviour of Defunct processes.

Hi All, Sorry to bother you all if my query is silly. Can you please clarify my doubts on defunct processes. Actually coming to the scenario, i have a server which is under cluster environment. Server B is having problems with the defunct process. There was a cron scheduled on Server B which... (0 Replies)
Discussion started by: reddybs
0 Replies

8. HP-UX

Defunct processes are getting generated

Dear Sir / Madam, We have two socket programs which are running in background. These two socket programs are creating defunct processes in HP-UX which were not happening in Compaq True64 UNIX. What is the root cause of these defunct processes and how can we correct it? Your suggestion will be... (3 Replies)
Discussion started by: kcsahoo
3 Replies

9. UNIX for Advanced & Expert Users

defunct processes?

HiI had a tool fail recently, on analysis I found it was cleaning up orphaned directories that had been created by specific processes that had died for some reason, thus failing to clean up after themselves.The directories were of the form /dir.pid. The tool would look to see if any instances of... (2 Replies)
Discussion started by: steadyonabix
2 Replies

10. HP-UX

Defunct Processes; Maximum Process

I'd like to remove this defunct processes without rebooting. Or, I could remove this defuncts when the maximum allowable process is nearly reached, then send an email to the user/team. How can I determine the maximum allowable process that a server can handle? Any thoughts? Jin@PRODUCTION: >... (3 Replies)
Discussion started by: Jin_
3 Replies
initctl(8)						      System Manager's Manual							initctl(8)

NAME
initctl - init daemon control tool SYNOPSIS
initctl [OPTION]... COMMAND [OPTION]... ARG... DESCRIPTION
initctl allows a system administrator to communicate and interact with the Upstart init(8) daemon. When run as initctl, the first non-option argument is the COMMAND. Global options may be specified before or after the command. You may also create symbolic or hard links to initctl named after commands. When invoked through these links the tool will behave only as that command, with global and command-specific options intermixed. The default installation supplies such links for the start, stop, restart, reload and status commands. OPTIONS
--system Communication with the init(8) daemon is normally performed over a private socket connection. This has the advantage of speed and robustness, when issuing commands to start or stop services or even reboot the system you do not want to be affected by changes to the D-Bus system bus daemon. The disadvantage to using the private socket however is security, init(8) only permits the root user to communicate over this socket which means that read-only commands such as status and list cannot be made by other users. The --system option instructs initctl to communicate via the D-Bus system bus rather than over the private socket. This is only possible if the system bus daemon is running and if init(8) is connected to it. The advantage is that the default security configuration allows non-root users to use read-only commands. --dest Specifies the well-known name of the init(8) daemon when using --system. There is normally no need to use this option since the init(8) daemon uses the default com.ubuntu.Upstart name. However it may be useful for debugging. --no-wait Applies to the start, stop, restart and emit commands. Normally initctl will wait for the command to finish before returning. For the start, stop and restart commands, finishing means that the named job is running (or has finished for tasks) or has been fully stopped. For the emit command, finishing means that all of the jobs affected by the event are running (or have finished for tasks) or have been fully stopped. This option instead causes these commands to only wait for the goal change or event to be queued. --quiet Reduces output of all commands to errors only. COMMANDS
start JOB [KEY=VALUE]... Requests that a new instance of the named JOB be started, outputting the status of the job to standard output when the command com- pletes. See status for a description of the output format. The optional KEY=VALUE arguments specify environment variables to be passed to the starting job, and placed in its environment. They also serve to specify which instance of multi-instance jobs should be started. Most jobs only permit a single instance; those that use the instance stanza in their configuration define a string expanded from environment variables to name the instance. As many unique instances may be started as unique names may be generated by the stanza. Thus the environment variables also serve to select which instance of JOB is to be acted upon. If the job is already running, start will return an error. stop JOB [KEY=VALUE]... Requests that an instance of the named JOB be stopped, outputting the status of the job to standard output when the command com- pletes. See status for a description of the output format and start for a discussion on instances. restart JOB [KEY=VALUE]... Requests that an instance of the named JOB be restarted, outputting the status of the job to standard output when the command com- pletes. See status for a description of the output format and start for a discussion on instances. Note that this command can only be used when there is an instance of JOB, if there is none then it returns an error instead of starting a new one. reload JOB [KEY=VALUE]... Sends the SIGHUP signal to running process of the named JOB instance. See start for a discussion on instances. status JOB [KEY=VALUE]... Requests the status an instance of the named JOB, outputting to standard output. See start for a discusson on instances. For a single-instance job a line like the following is output: job start/running, process 1234 The job name is given first followed by the current goal and state of the selected instance. The goal is either start or stop, the status may be one of waiting, starting, pre-start, spawned, post-start, running, pre-stop, stopping, killed or post-stop. If the job has an active process, the process id will follow on the same line. If the state is pre-start or post-stop this will be the process id of the equivalent process, otherwise it will be the process id of the main process. job start/pre-start, process 902 The post-start and pre-stop states may have multiple processes attached, the extra processes will follow on consecutive lines indented by a tab: job start/post-start, process 1234 post-start process 1357 If there is no main process, they may follow on the same line but will be prefixed to indicate that it is not the main process id being given: job start/post-start, (post-start) process 1357 Jobs that permit multiple instances have names for each instance, the output is otherwise identical to the above except that the instance name follows the job name in parentheses: job (tty1) start/post-start, process 1234 post-start process 1357 list Requests a list of the known jobs and instances, outputs the status of each to standard output. See status for a description of the output format and start for a discussion on instances. No particular order is used for the output, and there is no difference in the output (other than the instance name appearing in parentheses) between single-instance and multiple-instance jobs. emit EVENT [KEY=VALUE]... Requests that the named EVENT be emitted, potentially causing jobs to be started and stopped depending on their use of the start on and stop on stanzas in their configuration. The optional KEY=VALUE arguments specify environment variables to be included with the event and thus exported into the environment of any jobs started and stopped by the event. The environment may also serve to specify which instance of multi-instance jobs should be started or stopped. See start for a dis- cussion on instances. There is no limitation on the event names that may be emitted with this command, you are free to invent new events and use them in your job configurations. The most well known event used by the default Upstart configuration is the runlevel(7) event. This is normally emitted by the telinit(8) and shutdown(8) tools. reload-configuration Requests that the init(8) daemon reloads its configuration. This command is generally not necessary since init(8) watches its configuration directories with inotify(7) and automatically reloads in cases of changes. No jobs will be started by this command. version Requests and outputs the version of the running init daemon. log-priority [PRIORITY] When called with a PRIORITY argument, it requests that the init(8) daemon log all messages with that priority or greater. This may be used to both increase and decrease the volume of logged messages. PRIORITY may be one of debug, info, message, warn, error or fatal. When called without argument, it requests the current minimum message priority that the init(8) daemon will log and ouputs to stan- dard output. AUTHOR
Written by Scott James Remnant <scott@netsplit.com> REPORTING BUGS
Report bugs at <https://launchpad.net/upstart/+bugs> COPYRIGHT
Copyright (C) 2010 Canonical Ltd. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICU- LAR PURPOSE. SEE ALSO
init(8) telinit(8) shutdown(8) Upstart 2010-02-04 initctl(8)
All times are GMT -4. The time now is 04:19 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy