NVIDIA JETSON NANO 我有个开机自启动脚本,我想让他每次开机以root用户执行,我写入rc.local中为什么没起作用

我有个脚本想设定为开机自启动,我把他写到rc.local中没起到作用,注册为服务也没起作用是什么原因?这个脚本会在/dev/目录下创建一个usb-ffs的目录,里面包含usb bulk端点。

Hello,

Your topic will be best served in the Jetson category.

I will move this over for better visibility.

Cheers,
Tom

What do you see from this?
systemctl status rc-local.service

If this is not running/enabled, then “sudo systemctl enable rc-local.service”. There might be other issues, e.g., it has to be set as executable by root and readable by others.

Please note that creating nodes with mknod in “/dev” is mostly deprecated. There are times when this is still used if a node is used during boot stages, but if your node is not needed during boot, then I would expect loading the driver and the driver finding the hardware and attaching will cause the file to exist. Those device special files are not real files, but are instead a driver pretending to e a file. The old method, long ago, was that there was a registry of devices for “/dev”, but the list got so large that an automated device naming method had to be added. Even back in that time the node created was just a placeholder and did not do anything unless a driver attached to it. Beware that creating the node manually might be a problem.

Most “drivers” or tools for working with creation of files in “/dev” are from the hot plug system (udev) which is able to rename files, add multiple names to files in /dev, so on. However, the driver is still what creates the original file. An example of something udev might do is that upon plugin of a mouse or human interface device is to create optional names using different rules; those optional files are all symbolic links pointing at the original file which the driver created. Take a look at “ls -l /dev/input/by-id/*” and “ls -l /dev/input/by-path/*” and you will see symbolic links which point at the file the driver had created; the symbolic links were created by udev.

udev is also sometimes used for renaming files. For example, a vendor might provide a device which uses a standard driver so you don’t need a custom driver. However, the device might be proprietary and require a license. The serial number of the device could be embedded in the hot plug data that USB produces for that device upon plugin. udev could look for that if the rule is installed and rename just that one device while leaving alone other devices not of the expected serial number (any detail could be used, serial number is just an example). Then the software from that vendor could be set up to work only with those altered names despite using the same driver as all of the other similar hardware.

I suspect that using rc.local to create nodes in “/dev” is the wrong way to deal with what you are doing unless the software is terribly ancient. Think back to the time of the late 1990s or 2000s.

您好,请问有什么方式可以让某个脚本开机自启动吗?是注册为服务吗

我需要开机用root用户执行某个脚本!

Everything in rc.local runs as root if it is activated. init runs this content, and init is run as root (it’s really systemd with the name init). If it isn’t running as root, then what are the permissions of your rc.local?
ls -l /etc/rc.local

If you can answer the above it would help in knowing why the service fails (I am assuming you have started the rc-local.service).

Technically speaking, use of rc.local is out of date and normally not used in newer releases of many Linux distributions. One would create a systemd service if using newer methods.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.