I know modprobe can be used to load modules, but how does it decide
which modules to load?
When the kernel needs a feature that is not resident in the kernel, the kernel module daemon kmod
1 execs modprobe
to load the module in. modprobe
is passed a string in one of two forms.
- A module name like softdog or ppp.
- A more generic identifier like char-major-10-30
So, let me explain what I found in my system rather than pasting from the link.
cat /proc/modules
- This command lists what modules are loaded and the list is a pretty huge list.
Now, during the start up of the system, as I had already mentioned, the kmod
daemon executes the modprobe
to load the modules. We could specify the module to be loaded in either of 2 ways as already discussed. If we have specified a generic identifier, it will look for that entry in /etc/modprobe.conf
for alias. So, in my /etc/modprobe.conf
, I have an alias as below.
alias eth0 tg3
So, I ran the below command to check what is tg3 in my system.
-bash-3.2$ cat /proc/modules | grep tg3
tg3 139225 0 - Live 0xf8bd1000
Next, modprobe
looks through the file /lib/modules/version/modules.dep
, to see if other modules must be loaded before the requested module may be loaded. This file is created by depmod -a
and contains module dependencies.
Lastly, modprobe
uses insmod
to first load any prerequisite modules into the kernel, and then the requested module. modprobe
directs insmod
to /lib/modules/version/
[3], the standard directory for modules. insmod
is intended to be fairly dumb about the location of modules, whereas modprobe
is aware of the default location of modules, knows how to figure out the dependencies and load the modules in the right order.
But how is the new hardware detected?
These rings are created by CPU and not by OS. Any OS kernel operates in Ring 0 which is most privileged level and can communicate directly to the hardware and the CPU. Rings 1 and 2 are commonly used for device drivers. And ring 3 is used for user-space applications (media players, web servers and anything else user can communicate to directly). Device drivers are a “bridge” between user-space applications and hardware.
Linux kernel constantly scans all your computer bus’es for any changes and new hardware. Once any change on any bus is detected magic begins.
The Magic
- EXPORT HARDWARE INFORMATION TO USERSPACE (SYSFS)
- *NOTIFY USERSPACE TOOLS THAT HARDWARE IS AVAILABLE (UEVENT AND UDEVD)
- Yeah, your assumption is correct. udev has something to do with the magic :)*
- PROCESS UEVENTS, MATCH THEM AGAINST RULES IN /ETC/UDEV/RULES.D/ AND
POPULATE /DEV DIRECTORY (UDEVD AND UDEV)
- LOAD DEVICE DRIVERS (UDEV, MODPROBLE)
- NOTIFY USERSPACE APPLICATIONS (THROUGH D-BUS)
Udevd is just a daemon standing in between the Kernel and all the udev
system and perform some important functions (I’ll mention them later).
The udev daemon (udevd) is started at startup then reads and parses
all the rules found in /etc/udev/rules.d/ and keep these rules in
memory (udev database) for further usage by udev. Later udevd start to
listen on the netlink for uevents comming from Kernel driver core.
References
The hyphen (-
) found in an init script:
#!/bin/sh
#
# chkconfig: - 24 73
means that the service should not be started in any run levels by default, only stopped.
It replaces a list of run levels (e.g. 345) as shown below:
#!/bin/sh
#
# chkconfig: 345 24 73
Therefore if you use:
chkconfig --add <script>
then no start links will be created in any of the init
directories.
$ ll rc*.d/*script*
lrwxrwxrwx. 1 root root 17 Apr 24 2014 rc0.d/K73script -> ../init.d/script
lrwxrwxrwx. 1 root root 17 Apr 24 2014 rc1.d/K73script -> ../init.d/script
lrwxrwxrwx. 1 root root 17 Apr 24 2014 rc2.d/K73script -> ../init.d/script
lrwxrwxrwx. 1 root root 17 Apr 24 2014 rc3.d/K73script -> ../init.d/script
lrwxrwxrwx. 1 root root 17 Apr 24 2014 rc4.d/K73script -> ../init.d/script
lrwxrwxrwx. 1 root root 17 Apr 24 2014 rc5.d/K73script -> ../init.d/script
lrwxrwxrwx. 1 root root 17 Apr 24 2014 rc6.d/K73script -> ../init.d/script
Notice only the Kill
scripts links exist (K73script
).
References:
A reference to this can be found on softpanorama.org:
The first line tells chkconfig what runlevels the service should be started in by default, as well as the start and stop priority levels. If the service should not, by default, be started in any runlevels, a - should be used in place of the runlevels list.
Best Answer
killproc
needs the full file path of the program to kill, not just the program name. It preforms some sort of dictionary lookup and matches the full program path to the PID to kill.LSB stands for Linux Standards Base. It's designed to help maximise interoperability between different distros. However, CentOS ignores the LSB in places, particularly here (according to the standard,
/etc/init.d/functions
should be located in /lib, and should offer astart-daemon
function, among other things).Looking through the
killproc
source code, it seems that, if there's no pid file specified,killproc
searches through functions in the init.d, looking for a match to the program name specified. If it doesn't find it, it falls through to the if statement you traced to.If you look at the
crond
init script (which is pretty well written and helpfully clear about what's going on), it shows the proper invocation of killproc