I’m trying to get a cron job running every minute to check my VPN status and start if necessary. However, while the script works from the command line, cron doesn’t seem to be executing it. I have it defined in /var/spool/cron/crontabs/purism as this:
Note: I added the /bin/echo job to just check if this crontab is even kicking off, and it doesn’t seem to be, based on the lack of data in /tmp/file or /tmp/errors.
I checked if cron is running, and it is. Here’s the current status:
● cron.service - Regular background program processing daemon
Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2023-05-10 08:52:23 CDT; 5min ago
Docs: man:cron(8)
Main PID: 12260 (cron)
Tasks: 1 (limit: 3123)
Memory: 396.0K
CPU: 11ms
CGroup: /system.slice/cron.service
└─12260 /usr/sbin/cron -f -L 2
May 10 08:52:23 l5host systemd[1]: Started Regular background program processing daemon.
May 10 08:52:23 l5host cron[12260]: (CRON) INFO (pidfile fd = 3)
May 10 08:52:23 l5host cron[12260]: (purism) INSECURE MODE (mode 0600 expected) (crontabs/purism)
May 10 08:52:23 l5host cron[12260]: (CRON) INFO (Skipping @reboot jobs -- not system startup)
Having browsed stackexchange and other forums, I’ve added a PATH statement at the top, assuming environment differences between what cron is using vs purism account. I believe permissions are sufficient, and my command is executable. I’ve also tried to enable logging by enabling cron logging in rsyslog.conf, but after restarting both cron and rsyslog, I don’t get logs.
I didn’t interpret that as a blocker, but changed the file permissions to 0600, and it works now. Thanks and sorry for missing that. As an aside, I’m still not getting cron logs in /var/log/cron.log as specified in the rsyslog.conf file. The file is owned by root and is writeable.
Well it is a blocker if the permissions are too permissive such that it would break the Linux security model (e.g. allow one user to use the cron mechanism to run commands as another user! or e.g. allow one user to access information that is supposed to be private to another user). In other words, Linux is trying to stop you shooting yourself in the foot. On a single user device, yeah, it probably doesn’t make much difference.
A few other general comments about crontab:
On a single user device, I would tend to use the system crontab file and specify the user that the command is to run under on each line of the file. That way everything that is going to happen is centralised for your easy maintenance. (For example, that may better manage load, rather than inadvertently kicking off multiple jobs at the exact same time.)
I would tend not to specify I/O redirection in the command to be executed by cron. I don’t think it is explicitly specified as working, although there is an example in the man page using it, and whether it works could be affected by implementation changes.
Consequently I would always specify a shell script as the command to execute and redirect I/O inside the shell script in one way or other. In other words, the shell script keeps its own log file and doesn’t rely on the behaviour of cron.
Doing anything every minute may be bad for runtime on battery. It may be better to use the firewall to enforce use of the VPN if that is your intention. If the VPN if flaky, it may be better to investigate why that is and, if applicable, find a better provider.
I appreciate the input, thanks! Not wanting to spend a lot of effort parsing language with anyone, I’ll just say when I saw “INSECURE MODE,” it didn’t scream to me “this won’t work,” as much as seeing something like “Error” would have done. Being a novice in many respects, I took it as a learning experience, and again, sorry to have troubled the team on a simple matter.
Regarding the VPN, it’s not flaky; in fact, I’ve been very happy with the provider. My issue stems from a lack of ability within Network Manager or any other native Linux facility to seamlessly transition a VPN tunnel from one network interface to another when the former is no longer active. My VPN client I have on my iPhone does this; not having an Android, I presume it does there also. (Unfortunately, the provider’s Linux VPN client doesn’t do this. If there’s a VPN service that does, I’d welcome hearing about it.) The cron script I have is my attempt to duct tape a workaround. Having the firewall enforce the use of a tunnel would still require manual intervention on my part to enable that. While doable, albeit an inconvenience, I’d like to see if the script works well enough to achieve that, while not a perfect solution. I’ve seen in various forums ways of maybe doing this as well with routing rules, but I’m not savvy enough to make that happen, and I can envision scenarios where this won’t work either.
Regarding the battery life, the way I use the phone, I leave it plugged in overnight and during the day when I have it hooked up to my lapdock. I’ve basically swapped out my L13 for use of the L5. On the road, I can get at least 6 hours of runtime. If this process eats into that materially, then I may just suck it up and go back to doing this manually and add in the firewall enforcement you suggested.
OK, good point. I don’t think it will be possible to move (transition) the tunnel but it depends on exactly what tunneling protocol is being used. So you would have to accept that the old tunnel will fail (if the interface has gone down) and create a new tunnel (on the other interface).
Maybe you need to hook into the interface up/down script (discussed elsewhere in this forum) - so that when an interface comes up / goes down, you ensure that there is a tunnel over the best available interface.
To protect yourself while that is happening, you may want to use the firewall permanently to prevent any other traffic going direct to the internet.
Generally speaking, an event driven approach is preferred to a polling approach (i.e. notcron).
I initially tried the event driven approach to the extent that I configured my interfaces to automatically activate the VPN through Advanced Networking. I don’t know if modifying the up/down scripts would provide any more granular options. However, the mobile data interface would never come up, likely due to routing problems with the VPN configured on the wifi interface. In any case, I went through the path of least resistance.