[SOLVED] Are /sbin/hotplug script and scripts under /etc/hotplug.d/ directory not used now?
Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Are /sbin/hotplug script and scripts under /etc/hotplug.d/ directory not used now?
Hi,
In the Linux Device Driver 3rd edition book by Jonathan Corbet, Allessandro Rubini and Greg Kroah-Hartman I see like on any kobject event and after some filtering and environment information stuff added as argument to /sbin/hotplug script which will again invoke the required scripts under /etc/hotplug.d/ directory based on the environment data passed as arguments previously for hot plug mechanism.
But I could not see both /sbin/hotplug or /etc/hotplug.d/ directory in my laptop.
Are those not used now and replaced with some other mechanisms?
Unlike traditional Unix systems, where the device nodes in the /dev directory have been a static set of files, the Linux udev device manager dynamically provides only the nodes for the devices actually present on a system. Although devfs used to provide similar functionality, Greg Kroah-Hartman cited a number of reasons[4] for preferring udev over devfs:
udev supports persistent device naming, which does not depend on, for example, the order in which the devices are plugged into the system. The default udev setup provides persistent names for storage devices. Any hard disk is recognized by its unique filesystem id, the name of the disk and the physical location on the hardware it is connected to.
udev executes entirely in user space, as opposed to devfs's kernel space. One consequence is that udev moved the naming policy out of the kernel and can run arbitrary programs to compose a name for the device from the device's properties, before the node is created; there, the whole process is also interruptible and it runs with a lower priority.
The udev, as a whole, is divided into three parts:
Library libudev that allows access to device information; it was incorporated into the systemd 183 software bundle.[5]
User space daemon udevd that manages the virtual /dev.
Administrative command-line utility udevadm for diagnostics.
The system gets calls from the kernel via netlink socket. Earlier versions used hotplug, adding a link to themselves in /etc/hotplug.d/default with this purpose.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.