crontab removal

[Commadore Peaster]

Hi all,

K460, HP-UX 10.20 . I have one user who left and so I used " userdel -r login" to remove his account from that machine. After some time I started getting lots of emails about his cronjobs. I checked and found that his crontab entry in /var/spool/cron/crontabs was still there and it was getting executed, since his home directory was removed , i was getting the falied cronjobs email.

My question is userdel should have removed the users all data including his cronjobs. If not , whats the best way to do it ( rather than deleting it from /var/spool/cron/crontabs)

Thanks

[Brian M. Fisher]

The userdel command will not remove a users crontab file. The crontab command is an SUID program so the crontab files are owned by root not the user you deleted. All you need to do is remove the uneeded crontab file from /var/spool/cron/crontabs.

Brian
<*(((>< er

[Rick Garland · Accepted solution]

The userdel command does not work on the crontabs.

You could edit the crontab using crontab -e and then remove the entries in question.
If this crontab is as the user, the crontabs are in /var/spool/cron/crontabs/.
You could manually remove the crontab file for the user but I would save a backup copy. Then stop/restart the crontab process, this will force a reread if you do the manual removal.

[Jeremy Dean_3]

Write a wrapper for deleting users which does any local or additional housekeeping that userdel does not do.
This could include deleting crontab jobs, atjobs, mail file, pending printer jobs, ...

It may be advantageous to perform a special backup of the home directories / other infrastructure prior to running userdel. The user may run key infrastructure tasks under their login such as reporting, release control, ...

To delete the jobs, as your are running userdel as root you may just as well delete the physical file
/var/spool/cron/crontabs/${user}

I would also keep a logfile of who was deleted when, by whom and from which login client.

[Commadore Peaster]

Thank you all .
I think if the mails had not hit me , I would have not noted it. And its right to add a wrapper around userdel.
My colleague ( sun admin) told me that sun has a nice feature that , even if the crontabs of the user are not removed , the system checks if the user exists before executing his cronjobs and so if the user is non-existent his cronjobs will not get executed. I hope HP implements something in future patches. Not a big deal.

Thanks again,

[Tim Malnati]

I prefer to disable a user for a period of time instead of deleting them out immediately. There are a variety of audit trails that are impacted, particularly with database applications. As a minimum, I would hold on to the user existance until the next FULL database backup that is part of your long term backup strategy (not incremental). The best way to accomplish this is by locking out their password.

I also perform a find on the system looking for files that the user owns and keep a list of their attributes for auditing purposes. From this list I also review its contents and move any files that may have an impact to areas that I can have access to later. For instance, move the user crontab to a backup area. The jobs will no longer process, but you have a reference to what used to process in the event that something there is critical.