search

StatCan / aaw

Documentation for the Advanced Analytics Workspace Platform
https://statcan.github.io/aaw/
Other
68 stars 12 forks source link

Remote-desktop difficulty using CRON #1223

Closed Jose-Matsuda closed 2 years ago

Jose-Matsuda commented 2 years ago

Describe the bug

Came from Adib in the support channel

Environment info

Namespace:

Notebook/server: any remote-desktop

Steps to reproduce

To work around my earlier issue with cron not being installed on notebook servers, I created a Ubuntu VM which indeed has cron installed by default Verified using dpkg -l cron and also by the fact that the user level commands crontab -e is working. As per the manpages for cron, user level cron jobs are executed on the user level and does not need root access. I am able to write and install my own cronfile using crontab -e however the background daemon does not seem to be active. Verified using pgrep cron and ps -ef(no PIDs) Further verified using:

(base) jovyan@survey-scraper-0:/$ service cron status 
* cron is not running

Attempting to activate it using both systemctl start cron and service cron start results in errors...

(base) jovyan@survey-scraper-0:/$ systemctl start crond 
System has not been booted with systemd as init system (PID 1).
 Can't operate. Failed to connect to bus: Host is down

(^ this issue in particular is happening due to PID 1 being the process to start the VM) also,

(base) jovyan@survey-scraper-0:/$ service cron start * Starting periodic command scheduler cron  
cron: can't open or create /var/run/crond.pid: Permission denied

So I guess my question is, how is one supposed to use the user level cronfile as the user if they cannot activate the daemon?

Expected behaviour

Be able to use cron

Related information

I suspect if we install cron on the other images as wanted in https://github.com/StatCan/daaas/issues/1205 me may run into the same issue

chuckbelisle commented 2 years ago

We will not fix or implement this. For scheduled and recurring jobs Kubeflow pipelines should be used instead. Access to where the cron files live in the persistent volume requires elevated permissions which we cannot give.