0
What would you name the link to an init script that would kill a daemon?
Wiki User
∙ 13y agoWant this question answered?
Be notified when an answer is posted
Add your answer:
Earn +20 pts
What would you name the link to an init script that would kill the fictitious bigd daemon early in the boot process?
/etc/rc5.bigd.d
What would you name the link to an init script that would start the fictitious bigd daemon early in the boot process and what would you name the link to kill the same daemon?
/etc/rc5.bigd.dDoes someone copy some of these questions out of on-line tests or quizes? They seem too well written and too easy to answer to be real user questions.
What would you name the link to an init script that would start the fictitious bigd demon early in the boot process?
Kill -9
What would you name the link to kill the fictitious bigd daemon?
Kill -9
How do you kill a daemon in Linux?
kill pid
How would you use the service command to manually kill the bigd daemon?
Service bigd stop
Can you kill init process in Unix systems?
If you are the super-user you could kill the init process, however, it isn't recommended since no new tasks would be spawned and the system is likely to crash shortly thereafter.
How can you kill a orphaned process with ppid 1 I am not able to kill that with Kill -9 pid options.?
PID 1 on a Unix or Unix-like system is init. You cannot kill init.
What would you name the link to kill the same daemon?
This question makes no sense, it should be removed from the forum.
How would you use chkconfig to set the bigd daemon to start at runlevels 2 and 3?
Firstly, your script to control the bigd daemon must be written with specific reference to chkconfig. If you look at other scripts in /etc/init.d you will see many that follow a similar format to this (this is from the script /etc/rc.d/init.d/sshd):- #!/bin/bash # # Init file for OpenSSH server daemon # # chkconfig: 2345 55 25 # description: OpenSSH server daemon The three "numbers" following "chkconfig:" determine how chkconfig will add the script to the startup and shutdown events. The first number is actually a list of run-levels that the script should be started in. In this case, the sshd daemon will be started in run-levels 2, 3, 4 and 5. Ergo, in run-levels 0, 1 and 6 the sshd daemon will be stopped or killed. The second and third numbers control the order in which the process is started (55) and killed (25). A look a the list of entries in the rc.d directory for sshd should help explain this:- /etc/rc.d/init.d/sshd /etc/rc.d/rc0.d/K25sshd /etc/rc.d/rc1.d/K25sshd /etc/rc.d/rc2.d/S55sshd /etc/rc.d/rc3.d/S55sshd /etc/rc.d/rc4.d/S55sshd /etc/rc.d/rc5.d/S55sshd /etc/rc.d/rc6.d/K25sshd Each of the entries in the rcN.d (where N = 0 to 6) directories is a symbolic link back to the base script in /etc/rc.d/init.d/sshd. So when run-level 2 is initiated, /etc/rc.d/rc2.d/S55sshd is run. There are many other links in the /etc/rc.d/rc2.d to other scripts in /etc/rc.d/init.d, and the prefix added by chkconfig (i.e. S55 in the case of sshd) determines the sequence in which these scripts are performed. So sshd is started in run-level 2 after all the "earlier" entries have already been started (e.g. scripts starting with S10, S20, S30 etc.). For custom scripts, you would be advised to use a high number to start the script (e.g. 99) and a low number to stop/kill it. This will ensure all dependent processes are started when you start your script. To conclude, your bigd script should have something like this at the top of the file:- #!/bin/bash # # Init file for BIG server daemon # # chkconfig: 23 99 00 # description: Script to start bigd Then you can use "chkconfig --add bigd" to create all the symbolic links in the appropriate /etc/rcN.d directories. I hope that helps :)
What would you name a link to kill the same daemon?
SysVinit systems: service foo stop Systemd systems: systemctl stop foo.service
Why are PID numbers useful when you run processes in the background?
Process IDs are useful for backgrounded processes in cases where you need to either bring it into the foreground, send it a signal, or terminate/kill it. The reason for this is it's often not a good idea to identify a process by its program name lest there be multiple instances and you wish to address one of them. Process names are hardly unique, but running process IDs are. Thus when trying to background a process it's a good idea to make note of its PID. Daemons, on the other hand, don't necessarily require you to track its PID, as they are managed by the system's init system. If a daemon is misbehaving or needs management intervention by you, you can, as root, simply ask init, systemd, or whatever your distribution uses to pause or stop the daemon for a moment. Often when changing a daemon's configuration you use your init system to restart the daemon so it runs on the new config. Do not that daemons and even some other background processes are only under the control of root, or even more extremely, the kernel in kernel space, and you might not be able to do anything with them.
