Can't run cron jobs

[grantdobbe]

When trying to add a recurring job to my crontab, I get the following message:

crontab: installing new crontab
/var/spool/cron/: mkstemp: Permission denied

I'm able to work around the issue by using Task Scheduler to call bash.exe with the script I wanted to run, but that seems kludgy. A lot of applications depend on cron to run routine maintenance tasks, and having to set them up in Task Scheduler is sub-optimal.

[sunilmut]

@grantdobbe Unfortunately, we currently don't have support for background task execution. Please help us prioritize it by providing the feedback in our user voice page. I do see one related post, if you would like to up vote it.

[rodrymbo]

There is another issue: some normal userspace commands in linux are, for some reason, restricted to root, with no good reason (that is, it might make sense if the underlying NTFS filesystem prohibited it, which it usually doesn't). So even if cron background jobs worked, the current implementation denies permission for unprivileged users to use it. Lots of other things are in the same boat.

So for example, if you do sudo crontab -e and you don't get "permission denied", but you do get "permission denied" with plain crontab -e, this is not crontab not working, it is another of several unwarranted restrictions on linux unprivileged account behavior.

I'm not saying that cron is working, just that the crontab -e command is being denied to normal users without good reason. Making crontab work is thus, strictly speaking, a different issue. (In my opinion, there shouldn't be a question about it being a high priority.)

[matthewpersico]

sudo crontab -u $USER -e is a reasonable workaround. I'll upvote the cron support.

[ghost]

@sunilmut wrote:

Please help us prioritize [background task execution] by providing the feedback in our user voice page.

This is less than helpful for people who don't use UserVoice, but would like to see WSL support cron.

Microsoft already has, right here, a bug tracker for WSL. So, why ask people to go to UserVoice as well or instead? To fragment discussion? To increase the effort required, in the hope that people will give up instead of speaking up?

[sunilmut]

@sampablokuper -

To fragment discussion? To increase the effort required, in the hope that people will give up instead of speaking up?

That was definitely not the intent. This bug tracker is good for tracking bugs, but, it's difficult to do a consolidated voting based feature request here (nothing that I am aware of). If you have any feedback on how we take feature requests for WSL, please feel free to also reach out to @tara-raj

We actually look at our user voice page on feature requests. As for this particular request to support background tasks, that was added recently. See here. Hopefully that clarifies few things here.

We appreciate all feedback!

[ghost]

@sunilmut wrote:

To fragment discussion? To increase the effort required, in the hope that people will give up instead of speaking up?
That was definitely not the intent.

Good to have that confirmed :)

(Microsoft's track record re: user feedback, averaged over the last couple of decades, has, sadly, warranted the level of scepticism you can see in my comment above :/ )

it's difficult to do a consolidated voting based feature [requests in this bug tracker].

Is it? Enough to warrant fragmenting the "official" discussion threads across at least three different websites (GtiHub, UserVoice, Microsoft forums) run by three different companies?

Why not migrate the UserVoice feature requests to GitHub, ditch UserVoice, and then e.g. sort on the number of thumbs up per bug report in order to see which issues/features seem most wanted by the user base?

please feel free to also reach out to @tara-raj

Hi, @tara-raj . Done :)

As for this particular request to support background tasks, that was added recently. See here.

Thanks for the link. That is progress, but there's a long way to go until the behaviour as a whole is really cron-like.

[therealkenc]

The OP in this issue was:

crontab: installing new crontab
/var/spool/cron/: mkstemp: Permission denied

This is because cron(8) was not running, and that directory (possibly) did not have correct permissions. The 'possibly' caveat because no strace of the failing crontab(1) was provided.

The issue was marked as 'feature' because at the time WSL did not support background tasks. This was addressed in Insider 17046 and will hit the Spring Update RSN.

You can start cron with sudo service cron start.

$ sudo service cron start
 * Starting periodic command scheduler cron                              [ OK ]
$ ls -l /var/spool/cron
total 0
drwx-wx--T 1 root crontab 512 Apr  5  2016 crontabs
$ echo "*/1 * * * * echo hello \`date\` >> /tmp/hello" | crontab -
$ crontab -l
*/1 * * * * echo hello `date` >> /tmp/hello
$ cat /tmp/hello
hello Mon Mar 12 17:08:01 DST 2018
hello Mon Mar 12 17:09:01 DST 2018

If anyone finds any further problems with cron(8) or crontab(1) please feel encouraged to open a new issue following CONTRIBUTING.md. The popular github hang-out for launching of init tasks like cron (or sshd, or syslogd, or dbus-daemon, or ...) is #994.

[tara-raj]

Fixed in release 1803. You can read more about how to do this in our blog post on background tasks