Both expressions look like a Wednesday morning, and only one of them means once. 0 10 * * 3 fires at 10:00 on Wednesday; * 10 * * 3 fires at every minute of the ten o'clock hour, sixty chances to start the same tunnel. If the command is a launcher that does not check for an existing session, the second version is not a scheduling mistake, it is a loop that produces competing owners. Read the minute field before reading anything else.

The five fields are minute, hour, day of month, month and day of week, in that order, and a star in the first one means every minute.

The Minute Field Decides How Many Times

The leading number is the minute, so 0 10 * * 3 is the first minute of the tenth hour on Wednesday. Replacing it with a star keeps the hour and day and drops the once-only property, which produces sixty matches. Cron does not deduplicate: each match launches the command again. That is not a subtlety about cron, it is field semantics, and the installed scheduler's reference is worth reading because field order and the optional username column differ between user and system crontabs.

Test with a harmless command that records its own timestamp for a day. One line in the log is a schedule; sixty lines within an hour is a lesson.

What a Second Launch Does to the First

A well-behaved launcher notices that the connection is already up and does nothing. A raw openvpn invocation does not: it creates another process, another attempt to bind a device or a port, and another set of routes competing for the same destinations. On NetworkManager, repeated activation requests for one connection are usually idempotent, which is exactly why the problem stays hidden until somebody uses a different command. The schedule should ask the owner that already manages the tunnel.

Then decide what a request means while the connection is mid-connect. Neither duplicate activation nor a queue of pending starts is obviously correct; pick one and make the launcher implement it, rather than letting the scheduler decide by accident.

Count the Fields Before the Command

User and system crontabs differ in whether a username column appears before the command. An entry copied between them either runs as the wrong account or passes the username as the first word of the command. Check the installed reference rather than a guide, and count the fields in your own line. A five-field entry with a sixth word before the command is a system crontab; the same line in a user crontab tries to execute that word as a program.

The execution identity carries the environment with it. A cron job does not inherit an unlocked keyring, an interactive password prompt or the working directory you tested in.

Wait for Readiness, Not for the Clock

A successful launch is not a working tunnel. The client may still be resolving its endpoint, authenticating or installing routes when the job exits. Any dependent task should wait for the protected resource it actually needs, with a bounded timeout and a logged failure, rather than for a fixed number of seconds. That distinction separates a schedule that mostly works from one that fails silently on the busy morning.

If interactive MFA is required at that hour, the job can request a person's attention but cannot supply the response. Keep that case explicit instead of embedding a reusable password or retrying forever.

For a genuinely one-time activation, use the supported one-shot mechanism. A recurring rule that must be remembered and removed is a future duplicate launch.

פֿאַרבונדענע אַרטיקלען