I would like to update crontab entries for a non-root user for an application which gets installed as OpenPKG RPM package.
Currently I have this in the %post
section of my .spec file:
#
# Set up the 'app' user's crontab.
# Marker lines are used to separate content from different packages:
# #Begin of App package
# # ...
# #End of App package
# Replace any possibly existing content between these lines and insert the
# content of the installed new file
CRONTAB=/var/spool/cron/crontabs/%{V_user}
if [ -f $CRONTAB ]; then
begin=`head -1 %{V_instdir}/etc/crontab`
end=`tail -1 %{V_instdir}/etc/crontab`
if [ -z "$begin" ] || [ -z "$end" ]; then
echo "Error: Start or end delimiter line is empty. Check '%{V_instdir}/etc/crontab'"
exit 1
fi
sed -e "/^$begin/,/^$end/d" $CRONTAB > $CRONTAB.tmp
cat %{V_instdir}/etc/crontab >> $CRONTAB.tmp
mv $CRONTAB.tmp $CRONTAB
else
cp %{V_instdir}/etc/crontab $CRONTAB
fi
chown root:sys $CRONTAB
chmod 600 $CRONTAB
This does not work: The file is created correctly, but cron
does not pick up the changes. I suppose it is not allowed to edit the file in /var/spool/cron
directly.
What is the right way to edit the crontab?
- The
crontab
man page doesn’t mention a way to load a crontab for a user from a file. It doesn’t accept one from standard input. - Can I signal the
cron
daemon to re-read the crontab files? -
Or should I use
su
, along the lines ofsu %{V_user} -c "crontab -l > $tmpfile" # Make the changes su %{V_user} -c "crontab $tmpfile"
Wouldn’t this fail if the target user does not have permissions to edit his own crontab file?
The OS is Solaris 10. I don’t have root access. Someone else has to install the RPM package I create.
Best Answer
Unfortunately, cron(1M) doesn't accept any signals to reread crontabs. The way the crontab(1) tool communicates with cron is through interprocess communication (see the source). That said, it seems that crontab is probably the best tool you could use to modify a user's crontab. You could write a script that adds/deletes/modifies the crontab and use it as follows:
The script takes one argument, a name of the file that holds a copy of that user's crontab, processes the file, and exits with return code 0. crontab then will signal cron that a user's crontab has changed. In case you end up with an empty crontab, though, you have to change strategies and use
instead. A bit annoying.
The other possibility would be to just restart cron after your modification with
but that requires su or at least the solaris.smf.manage.cron right.