crontab -e crond

[itman007]

Can someone advise as to how I can add a job that shut down the pc after being booted to the remasterd dvd (6.7) I place the dvd in the optical drive and have lab pcs boot to that disk. I would like to have the remastered dvd have a job/script that will shutdown the pc say at 5 PM. I opened terminal and attampted to schedule using crontab -e via knoppix console and root. Both appeared to have no affect. Thanks for help and advice.

[lapidu]

Hi itman,

First you have to start cron with the following command:

sudo service cron start

After this, your scheduled tasks should run.

[itman007]

Thanks lapidu for that info. I feel that this would work fine but someone must enter that command each time the pc booted from the dvd/cd? I need to be bale to save or have that cron service start within the remastered environment so that each remaster would do this automatically. Your ideas? Thanks

[lapidu]

You have these options:

1) You mentioned the DVD you're booting is remastered. Why not enable cron by default in your remastered version?

2) Use persistent store. It will keep cron running once started. (Someone please correct me if I'm wrong about this).

3) Use knoppix.sh

[itman007]

I assume that should work. I will test to verify and post back here. Im a little stuck on the enable cron by default that you mention. I assume I can start cron within my persistent install and it will be syncd with my changes during remaster? Or do you mean enable it some other manor?

[lapidu]

Enabling cron by default should be possible by adding an entry to the appropriate script. I see that there is an entry in /etc/rc.local to start the cups service. I presume, but have not tested, that adding cron to that same file in a remastered version will thereafter ensure default starting of cron at boot. But I have cause for doubt after reading section 11.6 of the Debian FAQ - does the same apply to Knoppix, I wonder?. Perhaps you can run some tests and let us know, or someone with definitive knowledge will chime in.

Try starting cron within your persistent install and rebooting, then check whether cron remains running (for example, by scheduling a command and seeing whether it executes). If persistence keeps cron running, then your synchronised remaster will probably do the same.

[Capricorny]

Enabling cron by default should be possible by adding an entry to the appropriate script. I see that there is an entry in /etc/rc.local to start the cups service. I presume, but have not tested, that adding cron to that same file in a remastered version will thereafter ensure default starting of cron at boot. But I have cause for doubt after reading section 11.6 of the Debian FAQ - does the same apply to Knoppix, I wonder?. Perhaps you can run some tests and let us know, or someone with definitive knowledge will chime in.

Try starting cron within your persistent install and rebooting, then check whether cron remains running (for example, by scheduling a command and seeing whether it executes). If persistence keeps cron running, then your synchronised remaster will probably do the same.

Yes, adding "cron" to the services listing in /etc/rc.local is probably the best, and "Standard knoppix" way to get it going. Cups is already on the list, and I have, for example, added vmware services. And either using persistent store or hard-wiring it into a remaster, will keep it up. I haven't checked if there is an exception for cron - think that would be strange.

Because cron is a standard system service that actually should be up and running, I think it is better to start it from /etc/rc.local than from knoppix.sh.

As for persistence, the best is to run from USB or hard disk partition KNOPPIX copy. Normally, DC/DVD would, at worst, be used only for booting.

The standard way of setting up user's crontab is very user-friendly - if you are a skilled vi/vim user
Otherwise it will often feel like a hassle, I think. But use the standard way:

 
crontab -e

will set you up to vi-edit your crontab file. (The key sequence ESC :wq will write to file and exit, if there is an error in time setup, you will be asked to correct it.)

I haven't tried, but su-commands ought to be executable there. I try to avoid editing the system-wide /etc/crontab whenever possible, because screwing up that may in some cases produce serious problems.

Among usual cronjobs are different kinds of system backups prominent.

[Capricorny]

Update: Tried sudo shutdown and suhutdown in root's crontab file, in
/var/spool/cron/crontabs

System won't shut down that direct way, it seems. Not indirectly, either?
Scripts are being run, so cron is at work.

[klaus2008]

Greetings Capricorny!

Have you tried a line like

50 15 * * * /sbin/shutdown -h now

It worked on my system using Knoppix 7.0.3 CD.

[lapidu]

The standard way of setting up user's crontab is very user-friendly - if you are a skilled vi/vim user

Yes, surely I speak for quite a few of us when I say that developing our vim skills is on the to-do list! Interesting story behind the development of vi for anyone curious about why it seems so unusual to operate, search it up if you like.

Until then, here are some commands that will allow you to use another editor by default from your terminal when editing crontabs:

export EDITOR=nano    # Will make, e.g., nano the default editor until that shell is closed.


update-alternatives --config editor      # Will retain your selection system-wide.

As for certain commands not executing, klaus2008's solution will work; the full path of any executable is needed for user and root crontab because the path line, e.g....

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

...does not appear in them by default. You can, however, append the above PATH line to your user/root crontabs, and at the top of any scripts you wish to call via cron, instead of specifying full paths for each command separately. This has the advantage of increasing script portability across systems where the default path for executables might change, which case would necessitate lots of line-by-line updating of your script. The system-wide crontab specifies both shell and path.