Linux MintThis forum is for the discussion of Linux Mint.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
● cron.service - Regular background program processing daemon
Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2016-11-14 21:16:36 CST; 17h ago
Docs: man:cron(8)
Main PID: 862 (cron)
CGroup: /system.slice/cron.service
└─862 /usr/sbin/cron -f
Nov 14 21:16:36 mist-vm cron[862]: (CRON) INFO (pidfile fd = 3)
Nov 14 21:16:36 mist-vm cron[862]: (CRON) INFO (Running @reboot jobs)
Nov 14 21:16:36 mist-vm CRON[875]: pam_unix(cron:session): session opened for user root by (uid=0)
Nov 14 21:16:36 mist-vm CRON[876]: pam_unix(cron:session): session opened for user root by (uid=0)
Nov 14 21:16:36 mist-vm CRON[912]: (root) CMD (/home/mist/Documents/test.sh)
Nov 14 21:16:36 mist-vm CRON[913]: (root) CMD (/home/mist/Documents/foo.sh > /home/mist/Documents/log.txt)
Nov 14 21:16:36 mist-vm CRON[875]: (CRON) info (No MTA installed, discarding output)
Nov 14 21:16:36 mist-vm CRON[875]: pam_unix(cron:session): session closed for user root
Nov 14 21:16:36 mist-vm CRON[876]: (CRON) info (No MTA installed, discarding output)
Nov 14 21:16:36 mist-vm CRON[876]: pam_unix(cron:session): session closed for user root
@jpollard the file showed in Documents, but only after i cycled the service.
Also, i was messing around with rc.local and after i cycled the service the script was running. Now, im wondering if its caused by run levels. Cron is set for lv 2/3/4/5 and rc.local is set for 2/3/4/5 and i added 6 and S
Yes, however I also increased the run time to 200 seconds. Not sure how long it takes the VM to start but 120 seconds may not of given me enough time to verify the script was running.
Starting cron or rc.local in runlevel 6 will not do anything. I also just tested the script by running it from rc.local and it also worked. I did not have to change or start any services from whatever Mint sets as default.
Yes, however I also increased the run time to 200 seconds. Not sure how long it takes the VM to start but 120 seconds may not of given me enough time to verify the script was running.
adding delays may help... but you can't be sure of how long you have to wait. What works at one time may not work the next.
Quote:
Starting cron or rc.local in runlevel 6 will not do anything. I also just tested the script by running it from rc.local and it also worked. I did not have to change or start any services from whatever Mint sets as default.
Adding "run levels" won't make any difference. systemd only fakes the run levels - they run as soon as the system thinks the network is "ready", not necessarily when the network is usable (that requires an additional service - "NetworkManager-wait-online"). Along with that are any other services being started at the same time.
Not sure why the network being ready or not affects either cron, rc.local or the test script in this circumstance. Or am I missing something.
It all depends on the environment the script is running in and what it needs. If the script needs database access, automounting, or something remote - it can fail.
Even now, local mounts may be done in some parallel order - which may cause other failures (which may be why the sleep time suddenly worked, where it didn't before). Another thing that can change the order is if you us ypbind. If this service is enabled, then suddenly the crond will wait until after it is active, which would appear totally unrelated... (it isn't, as systemd assumes that the user identities used by crond must be taken from a ypbind service, or maybe it is assuming NFS must be being used...).
This is why adding things to systemd configurations is tricky - sometimes it works, sometimes not, adding a delay works, sometimes not. The problem is the complexity of the systemd dependency network.
The present script SHOULD work (even without the time delays)... but like I said, the run levels run anytime after the network is "ready", but that doesn't mean other services are ready if the script is modified to use one of them.
@michaelk how do you initiate the script? I have also created VM with Mint 18, and it doesn't work. I havent changed any settings. Im out of ideas now.
the first thing I would try is to redirect stdout/stderr of crontab entry into a local file.
next, I would remove the redirection to /dev/null in test.sh
also you can do a touch "/tmp/here_we_are" in the crontab (or similar) just to check if that works
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
