Results 1 to 3 of 3

Thread: cronjob for amanda not working.

  1. #1
    Join Date
    Feb 2012
    Posts
    5

    Default cronjob for amanda not working.

    Hi,

    For some reason, the cron jobs I have set up for amcheck and amdump seem to have stopped working. I'm wondering if it's the syntax of the crontab or if something on the (centos) linux box I'm working with has an issue.

    I set these crontab entries as root when the amandabackup's crontab stopped working:

    # amanda check config for issues
    0 16 * * * su amandabackup -c /usr/sbin/amcheck -m adready.local
    # amanda run backup (will automatically make full and incremental)
    30 16 * * * su amandabackup -c /usr/sbin/amdump adready.local

    original crontab entries as amandabackup:

    0 18 * * * /usr/sbin/amcheck -m adready.local
    15 0 * * * /usr/sbin/amdump adready.local


    The last attempted runs had this result from /var/log/cron:

    Feb 26 18:00:01 hqadmin02 crond[13978]: CRON (amandabackup) ERROR: failed to open PAM security session: Bad file descriptor
    Feb 26 18:00:01 hqadmin02 crond[13978]: CRON (amandabackup) ERROR: cannot set security context
    Feb 27 00:15:01 hqadmin02 crond[3764]: CRON (amandabackup) ERROR: failed to open PAM security session: Bad file descriptor
    Feb 27 00:15:01 hqadmin02 crond[3764]: CRON (amandabackup) ERROR: cannot set security context
    Feb 27 18:00:02 hqadmin02 crond[2476]: CRON (amandabackup) ERROR: failed to open PAM security session: Bad file descriptor
    Feb 27 18:00:02 hqadmin02 crond[2476]: CRON (amandabackup) ERROR: cannot set security context
    Feb 28 00:15:01 hqadmin02 crond[24572]: CRON (amandabackup) ERROR: failed to open PAM security session: Bad file descriptor
    Feb 28 00:15:01 hqadmin02 crond[24572]: CRON (amandabackup) ERROR: cannot set security context

    If I ps aux | grep amdump, there's no instance of it, so I'm getting the impression that something is wrong with the cron syntax.

  2. #2
    Join Date
    Mar 2012
    Posts
    1

    Default

    Quote Originally Posted by rmarquez View Post
    Hi,

    For some reason, the cron jobs I have set up for amcheck and amdump seem to have stopped working. I'm wondering if it's the syntax of the crontab or if something on the (centos) linux box I'm working with has an issue.

    I set these crontab entries as root when the amandabackup's crontab stopped working:

    # amanda check config for issues
    0 16 * * * su amandabackup -c /usr/sbin/amcheck -m adready.local
    # amanda run backup (will automatically make full and incremental)
    30 16 * * * su amandabackup -c /usr/sbin/amdump adready.local

    original crontab entries as amandabackup:

    0 18 * * * /usr/sbin/amcheck -m adready.local
    15 0 * * * /usr/sbin/amdump adready.local


    The last attempted runs had this result from /var/log/cron:

    Feb 26 18:00:01 hqadmin02 crond[13978]: CRON (amandabackup) ERROR: failed to open PAM security session: Bad file descriptor
    Feb 26 18:00:01 hqadmin02 crond[13978]: CRON (amandabackup) ERROR: cannot set security context
    Feb 27 00:15:01 hqadmin02 crond[3764]: CRON (amandabackup) ERROR: failed to open PAM security session: Bad file descriptor
    Feb 27 00:15:01 hqadmin02 crond[3764]: CRON (amandabackup) ERROR: cannot set security context
    Feb 27 18:00:02 hqadmin02 crond[2476]: CRON (amandabackup) ERROR: failed to open PAM security session: Bad file descriptor
    Feb 27 18:00:02 hqadmin02 crond[2476]: CRON (amandabackup) ERROR: cannot set security context
    Feb 28 00:15:01 hqadmin02 crond[24572]: CRON (amandabackup) ERROR: failed to open PAM security session: Bad file descriptor
    Feb 28 00:15:01 hqadmin02 crond[24572]: CRON (amandabackup) ERROR: cannot set security context

    If I ps aux | grep amdump, there's no instance of it, so I'm getting the impression that something is wrong with the cron syntax.
    So the cron jobs work when you run them as root?

    One quick thing to check: make sure the amandabackup user has a valid shell. It can't run cron jobs unless its using a valid shell. The default for daemon users is to give them an invalid shell (for security reasons), but in this case you'll need to change that. Look in /etc/passwd and see if the shell for the Amanda user is something like /bin/false; change it to /bin/bash.

    The PAM messages look strange... certainly could be due to a syntax error in a file somewhere.

  3. #3
    Join Date
    May 2009
    Posts
    82

    Default

    I had this problem some time ago and it turned out to be an authentication problem. In my case the amandabackup user was an active directory user and all I had to do was stop and start the services that bind the Redhat system to the Microsoft domain.

    service smb stop
    service winbind stop
    service smb start
    service winbind start
    # Test it
    wbinfo -u

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •