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
Requires directives in systemd.unit(5)), and constrained by
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:
- mark your device with a "systemd" tag, so systemd creates a device unit for it;
- 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;
systemctl edit wvdial.service to add
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.