I have a question about the daemon’s networking.service.
I want to speed up the startup time of Jetson Nano.
So, when I investigated Jetson’s startup time, I found that the startup time of networking.service was a bottleneck, so I’m considering stopping it.
Which documentation should I read to learn about the features of networking.service?
I can’t fully answer, but here are some random facts which might be useful:
sudo systemctl disable networking.service”.Thank you.
I have checked all the search results for your link.
But I couldn’t come up with the answer.
I stopped networking.service and found that Linux boot time was significantly reduced.
But I can’t explain to others what has stopped working.
Even if the daemon is stopped, SSH connection is possible via LAN, and CAN communication is also possible.
So I searched for something like an official doc that describes the functionality of the daemon, but couldn’t find it.
Do you know what is stopped by stopping networking.service?
I am thinking the USB virtual wired ethernet might not be tied in to systemd, which would mean USB virtual wired won’t care about whether systemd networking is enabled or not. Do you use the USB virtual wired ethernet which provides the 192.168.55.1 IP address?
CAN is likely similar in that it depends on a driver and hardware without using systemd for init.
Basically you need to know what interfaces are managed by systemd to know if stopping something on systemd (which is what “networking.service” is…a systemd service) will stop that communications. Each of those non-systemd services would have its own configuration. In the case of CAN it is likely device tree plus some config file (I don’t know for sure, I have never tried to configure CAN…device tree is for hardware setup and driver arguments, but other config would be a file somewhere, probably in “/etc”). For the USB virtual wired ethernet, the configuration is in:
/opt/nvidia/l4t-usb-device-mode
Within that /opt device mode directory there are in fact some systemd compatible scripts, but I suspect that they are not tied directly to networking.service. To demonstrate, run this command:
systemctl list-units | grep 'l4t'
You should find the bridge which is used by the virtual USB ethernet, but the actual virtual ethernet would be “nv-l4t-usb-device-mode.service”. One could then cd to “/etc/systemd”, and run this command:
find . -name '*l4t*'
…which would point out this local config (I’m looking at an old TX2 install, so this might differ from your Nano):
./system/multi-user.target.wants/nv-l4t-usb-device-mode.service
./system/nv-l4t-usb-device-mode.service
It seems that hitting text mode multi-user.target enables the USB wired ethernet. One could rearrange those files in “/etc/systemd/system” and tie USB wired to networking.service instead of being tied to “mutli-user.target”. There is a good reason why this was not actually done: The purpose of the virtual wired ethernet is for flashing a system which may not have networking…add to this that device mode enables more than just the virtual wired ethernet, it also enables a block device example, and that block device is needed even when networking is not enabled. Combine this with the fact that the USB virtual wired ethernet is for working on a system with no “standard” ethernet networking. I suppose the real “best and politcaly correct” way to modify this would be to keep all non-networking services in the existing “nv-l4t-usb-device-mode.service”, but to separate out the virtual wired ethernet into its own service, and combine this with the wants/needs of “networking.service”.
I don’t know which service CAN is tied to (if any…perhaps it isn’t managed at all by systemd), but this would be a similar story where it might (or could be) tied to networking.service, but is not currently tied to it.