0

I would like to ask about methods of starting application at boot in modern Linux (kernel 3.x, 4.x, 5.x), their advantages and disadvantages.

I know 3 methods:

  • cron
  • /etc/rc.local
  • systemd script

however I don't know:

  • when should I use which method?
  • in which order these methods run?
  • are there other methods?

In this particular case I need to start a script, which executes wvdial and keeps dialup connection up.

Can I just put it in /etc/rc.local and be sure that udev finished /dev/ttySomeModem exists, my USB modem driver is loaded? Or maybe I have to use systemd and add udev dependency?

I'm using udev to execute usb_modeswich when modem is connected and generate /dev/ttyUSB* symlinks to modem serial ports when modem switches from mass storage to modem mode.

2
  • Which distribution are you using, is it using systemd? Nov 29 '20 at 9:25
  • @MarkScheck Yes, it is using systemd, it's Debian (I'm also using Raspbian, but they are very similar).
    – Kamil
    Nov 29 '20 at 14:44
3

Let me answer the specific questions first, and then I'll generalize a bit to hint at the solution for your wvdial problem.

in which order these methods run?

Cron runs every minute, and executes commands that are due at that particular minute. Cron is unrelated to boot, except it obviously doesn't run anything while the machine is off.

/etc/rc.local runs "last". With System V init (pre-sysemd), it's really the last thing to run before the system is considered booted. With systemd, it's ran once the network is up, but concurrently with other services.

systemd units are ran as early as possible, in parallel with their dependencies (see Wants and Requires directives in systemd.unit(5)), and constrained by Before and After directives. systemd makes a distinction between ordering of units and their dependencies.

when should I use which method?

Use Cron if you need something to be executed periodically. With systemd, you can also use timers for this.

rc.local is rarely the correct answer, and should be avoided. Consider editing a config of the appropriate service, change the script for that service, or write a new one. See this blog post for an expanded explanation of this.

systemd units is what you should be using most of the time (but see below). On System V, use services instead.

are there other methods?

You've listed the major ones, but there are specialized facilities for some other tasks. For example, udev can run scripts upon certain events. Desktop environments like KDE or Gnome provide auto-start capabilities. As a rule of thumb, do the work at the point where it makes the most sense; e.g. use KDE autostart to launch your audio player, but use systemd to start OpenSSH server.

In this particular case I need to start a script, which executes wvdial and keeps dialup connection up.

This is an interesting case: you need to initialize a device, and then run a service. The least hacky approach I can think of is:

  1. mark your device with a "systemd" tag, so systemd creates a device unit for it;
  2. write a one-shot unit that depends on the device unit. It should run usb_modeswitch and create the symlinks — the same stuff that your existing udev handler does;
  3. systemctl edit wvdial.service to add Requires= and After= directives, making wvdial depend on the one-shot unit you created. This would delay wvdial until after the modesetting is done.

A slightly more hacky way to do it is to keep the udev handler, and amend the wvdial service to busy-wait for symlinks to appear.

You might also need to teach NetworkManager about wvdial, so NM knows to re-dial if the device was unplugged then plugged back — but I'm not sure, since I never actually used modems.

1
  • 1
    Thank you for your comprehensive answer. When I wrote about cron - I know that it runs periodic tasks, but it is possible to add "@reboot" entry. However after re-thinking this I guess that cron first run is when systemd starts cron, and using it for this is a bad idea.
    – Kamil
    Nov 30 '20 at 17:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.