crontab -e crond

[Capricorny]

Thanks a lot to klaus2008 and lapidu!

I think you have given excellent instructions. One reason I didn't mention the alternative editor setup, is that unless one is very adept at another editor, like nano, it may be just as smart to use the vi/vim default. In practice, it will always be available on a system, but, for example, my own standard editor, emacs, will not.

I will also advise to use your user's crontab whenever possible.

Summing up

1. Edit /etc/rc.local

SERVICES="cups cron"

for i in $SERVICES; do
 [ -x /etc/init.d/"$i" ] && /etc/init.d/"$i" start >/dev/null 2>&1
done

2. Edit user's crontab to include shell and PATH, you may copy from /etc/crontab. This works for me to auto-shutdown at 17.00 every day:

#
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# m h  dom mon dow   command
0 17 *    *    *      sudo shutdown -h now

3. To test the setup, I find Qemu very useful. I have several grub-bootable Poor Man's Installs on the main harddisk, so I use

sudo modprobe kvm && sudo modprobe kvm-intel
sudo qemu -machine accel=kvm -hda /dev/sda -m 2047 &

and just pick up one alternative to test. Be a bit careful during testing - I set it up to shutdown every third minute, and I barely managed to edit that to something else before the system went down (Could of course have mounted the persistent image "off-line".)

4. As for the original problem posted, I must say that I will, generally, advise against remastering a DVD with hard-wired shutdown at 5 o'clock - now that we know it works . For example, the computer's clock may not always be set correctly. I think it is way better to use persistent store on USB sticks for that, and just boot from DVD when necessary. But if there are, for example, special safety concerns, it can of course be done.

[itman007]

I have failed so far at the attempt to get the persistent installation to shutdown at scheduled time. rc.local now starts cron upon boot properly but /etc/crontab doesnt reboot the pc at time I specify. I have configured it to shutdown at 10 AM but the unit has not shut down.
My /etc/crontab file contains the below:

# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# m h dom mon dow user command
00 10 * * * sudo shutdown -h now
#17 * * * * root cd / && run-parts --report /etc/cron.hourly
#25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
#47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
#52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )


Please advise if anyone sees the problem here. Keep in mind this Knoppix 6.7

[Werner P. Schulz]

Only root has permission for "shutdown"; therefore start with "crontab -e" in a root-terminal and use

00 10 *    *    * /sbin/shutdown -h now

[itman007]

This is issue is resolved. Thanks for everyone's input. For those whom wish to schedule a shutdown in Knoppix 6.7 you must add the word cron to the /etc/rc.local as seen in the sample below. Then edit your /etc/crontab to add a line such as mine, 0 10 * * * root /sbin/shutdown -h now Which will shutdown at 10AM using the user root.


#!/bin/bash
#
# rc.local
#
# Start local services after hardware detection

SERVICES="cups cron"

for i in $SERVICES; do
[ -x /etc/init.d/"$i" ] && /etc/init.d/"$i" start >/dev/null 2>&1
done

exit 0

[Capricorny]

The method summarized in #11 works. Personally, I would stay away from /etc/crontab for this, as user's crontab, with shell and path specifications, works just fine. No need for root either,
If there are several different users on the system, using /etc/crontab may help coordinate different cronjobs. If there is just one or two, user's crontab should be good enough. Intimidating as it may be, I have found it useful for me to stick with crontab -e --- for several reasons, among them that some time definition errors will be caught that way.