Scheduled backups aren't triggered

31 posts / 0 new
Last post
#1 Tue, 06/02/2009 - 09:06
ipsa

Scheduled backups aren't triggered

Hi,

I've setup scheduled backups (full monthly, incremental daily) on my server and they don't seem to get triggered.

The root user's crontab contains this:

@monthly /etc/webmin/virtual-server/backup.pl --id 123974394718634 @daily /etc/webmin/virtual-server/backup.pl --id 123974406619089

and if I execute either one of those commands manually at the command line, the backups gets done as expected. Same if I do it manually in the Virtualmin web interface.

I'm running Virtualmin 3.68 Pro on CentOS Linux 5.3.

Is there a problem with crontab? Maybe the "@word" notation?

Thanks

Tue, 06/02/2009 - 09:23
andreychek

Howdy,

Well, those 2 entries look okay.

What happens if you restart cron, then look in /var/log/messages -- do you see any errors in there?

It's possible that an error with a different cron entry is causing cron in general to bail out.
-Eric

Tue, 06/02/2009 - 11:48 (Reply to #2)
ipsa

I did "service crond restart" and nothing got added to /var/log/messages. I'm assuming that means that the restart occurred without any error.

Tue, 06/02/2009 - 12:19 (Reply to #3)
andreychek

Well, you should see at least a message stating that it restarted.

If you don't see that, it's in one of the other files there. But I forget which, I don't have a CentOS machine right here :-)
-Eric

Tue, 06/02/2009 - 14:55 (Reply to #4)
Joe
Joe's picture

crond is the right service. I don't see any messages when restarting it on my system, either. So, I guess we can't use that as an indicator of anything. ;-)

--

Check out the forum guidelines!

Wed, 06/03/2009 - 09:29 (Reply to #5)
ipsa

I'm all for simplifying my life but isn't SELinux a good thing? I don't know much about it but disabling it wholesale seems a little extreme. Does it not bring advantages that would outweigh a few minutes/hours spent configuring it correctly?

Anyway, I'll do it if the other solution is really heinous and cludgy and SELinux isn't worth it, but I'd like to know more before doing so.

Wed, 06/03/2009 - 09:42 (Reply to #6)
andreychek

How about this -- can you try disabling SELinux temporarily -- and if that does indeed solve the problem, you can then decide what direction to move from there.

If it doesn't solve the problem, well, then something else is hindering cron and the backups :-)

To do that, just run:

echo 0 > /selinux/enforce
/etc/init.d/crond restart

Check out the cron log file, and see if those errors persist.

You can easily re-enable selinux with:

echo 1 > /selinux/enforce

Wed, 06/03/2009 - 10:35 (Reply to #7)
Joe
Joe's picture

SELinux is a good thing, but the reliability of it and its policies on most distros currently leaves much to be desired. And, the tools for managing policy truly and completely suck.

Most importantly, though, not having cron is a pretty big problem, and you need to take steps to get the problem corrected. ;-)

If you know what you're doing with SELinux (and are OK with users being pretty serious restricted, and occasional mysterious errors) then you could turn it back on after testing with it turned off. Virtualmin has the beginnings of support for setting context for files and such (though it's still a long way from complete, so your policy will need to be pretty open for users).

--

Check out the forum guidelines!

Wed, 06/03/2009 - 06:43
ipsa

So, I've restarted the service again and this line got added to the /var/log/cron file:

Jun 3 11:36:30 server crond[9148]: (CRON) STARTUP (V5.0)

In the same file, there's a whole bunch of messages like this:

Jun  3 00:00:01 server crond[3114]: Cannot make/remove an entry for the specified session
Jun  3 00:00:01 server crond[3114]: CRON (root) ERROR: failed to open PAM security session: Success
Jun  3 00:00:01 server crond[3114]: CRON (root) ERROR: cannot set security context
Jun  3 00:00:01 server crond[3116]: Cannot make/remove an entry for the specified session
Jun  3 00:00:01 server crond[3116]: CRON (mailman) ERROR: failed to open PAM security session: Success
Jun  3 00:00:01 server crond[3116]: CRON (mailman) ERROR: cannot set security context
Jun  3 00:00:01 server crond[3118]: Cannot make/remove an entry for the specified session
Jun  3 00:00:01 server crond[3118]: CRON (root) ERROR: failed to open PAM security session: Success
Jun  3 00:00:01 server crond[3118]: CRON (root) ERROR: cannot set security context
Jun  3 00:00:01 server crond[3122]: Cannot make/remove an entry for the specified session
Jun  3 00:00:01 server crond[3122]: CRON (root) ERROR: failed to open PAM security session: Success
Jun  3 00:00:01 server crond[3122]: CRON (root) ERROR: cannot set security context
Jun  3 00:00:01 server crond[3119]: Cannot make/remove an entry for the specified session
Jun  3 00:00:01 server crond[3119]: CRON (root) ERROR: failed to open PAM security session: Success
Jun  3 00:00:01 server crond[3119]: CRON (root) ERROR: cannot set security context

These are all from midnight last night, when it should have tried to to the incremental backup (and a whole bunch of other things, I assume). I'm assuming there's a link but since CentOS isn't my usual platform, I'll be asking google after posting here.

Wed, 06/03/2009 - 06:59 (Reply to #9)
andreychek

Aha! I think you're having an SELinux problem.

Now, the above should usually work -- SELinux shouldn't prevent cron jobs from running.

But, to simplify your life a bit -- you might consider simply disabling SELinux.

Take a look in /etc/selinux/config -- I would suggest setting "SELINUX=disabled" in there.

Also, to prevent having to reboot, you can run this (as root):

[code:1]echo 0 >/selinux/enforce[/code:1]

Which will manually switch it off -- and the next time you reboot, the changes to the config file will prevent it from coming on at all.
-Eric

Wed, 06/03/2009 - 12:33
ipsa

Okay,

I tried to disable SELinux as suggested by running this:

echo 0 > /selinux/enforce

and then restarted crond. Those same message continue to appear in the cron log file.

It seems that by running the command above, I created a folder named "selinux" at the root and a file named "enforce" inside it with "0" as its content. (There's nothing else in the folder and its date show as being a few moments ago.)

I understand from the notation that that's what it is supposed to do, but I figured "selinux" was a special folder (like proc).

Is something else wrong here?

Wed, 06/03/2009 - 13:00 (Reply to #11)
Joe
Joe's picture

Hehehe...Actually you can use:

setenforce 0

Not sure what Eric was after with the echo command...I guess there probably is a /proc entry for selinux. I dunno what it is, though.

--

Check out the forum guidelines!

Wed, 06/03/2009 - 14:46 (Reply to #12)
andreychek

Hrm, when SELinux is enabled, there should be a /selinux directory that is a bit like /proc.

That not being there suggests to me that it's either not enabled, or that my information is really old. Either is totally plausible :-)
-Eric

Wed, 06/03/2009 - 14:48 (Reply to #13)
Joe
Joe's picture

Actually, you're right. There is an /selinux directory. There is no "enforce" in my system, though.

--

Check out the forum guidelines!

Thu, 06/04/2009 - 05:31
ipsa

Okay, SELinux is disabled.

[code:1]bash-3.2# setenforce 0
setenforce: SELinux is disabled[/code:1]

I then restarted cron and monitored the /var/log/cron file. Here's its contents after a few minutes:

[code:1]Jun 4 10:22:26 server crond[26301]: (CRON) STARTUP (V5.0)
Jun 4 10:25:02 server crond[26880]: Cannot make/remove an entry for the specified session
Jun 4 10:25:02 server crond[26880]: CRON (mailman) ERROR: failed to open PAM security session: Success
Jun 4 10:25:02 server crond[26880]: CRON (mailman) ERROR: cannot set security context
Jun 4 10:25:02 server crond[26881]: Cannot make/remove an entry for the specified session
Jun 4 10:25:02 server crond[26881]: CRON (root) ERROR: failed to open PAM security session: Success
Jun 4 10:25:02 server crond[26881]: CRON (root) ERROR: cannot set security context
Jun 4 10:26:01 server crond[27254]: Cannot make/remove an entry for the specified session
Jun 4 10:26:01 server crond[27254]: CRON (root) ERROR: failed to open PAM security session: Success
Jun 4 10:26:01 server crond[27254]: CRON (root) ERROR: cannot set security context[/code:1]

This isn't for the backups specifically, but something seems to still be wrong with cron.

Thu, 06/04/2009 - 10:53 (Reply to #15)
andreychek

What distro/version are you using?

And is everything fully up to date -- all the latest patches and updates made available by the vendor have been applied?

There's some issues similar to what you're seeing on some older versions of RHEL/CentOS/Fedora, but they all should have been resolved by the latest updates.
-Eric

Fri, 06/05/2009 - 06:06
ipsa

I'm running Virtualmin 3.68 Pro on CentOS Linux 5.3.

I'm not fully up to date. yum has a problem updating some clamav stuff (it seems to be looking for /usr/bin/freshclam, which is there but it's still complaining that it is missing; wouldn't mind pointer with that one either).

As a crutch until this cron issue is fixed, I'm using the cron on my local box to SSH into the server and run the scripts. It's not pretty, but it works.

Fri, 06/05/2009 - 06:50 (Reply to #17)
andreychek

Well, as a last resort, we have the option of disabling SELinux entirely by editing /etc/selinux/config (all we did is change it to permissive mode, which prevents it from enforcing it's ruleset), and then rebooting.

But, rebooting production servers sucks, so a couple of other thoughts before we get to that point --

What are the contents of the following files:

1. /etc/cron.deny

2. /etc/cron.allow

3. /etc/security/access.conf

4. /etc/pam.d/crond

It's possible something in one of those will stand out as the culprit.
-Eric

Fri, 06/05/2009 - 07:36 (Reply to #18)
ipsa
  1. /etc/cron.deny is empty

  2. /etc/cron.allow doesn't exist

  3. /etc/security/access.conf only contains commented lines

  4. Here are the contents of /etc/pam.d/crond:

auth    sufficient pam_rootok.so
auth       required   pam_env.so
auth       include    system-auth
account    required   pam_access.so
account    include    system-auth
session    required   pam_loginuid.so
session    include    system-auth

Hopefully something here will help avoid a reboot.

Thanks!

Fri, 06/05/2009 - 10:27 (Reply to #19)
andreychek

Yeah, none of those looks like a culprit.

What does this command output:

yum check-update

Fri, 06/05/2009 - 11:21 (Reply to #20)
ipsa

This is what the command "yum check-update" outputs:

[code:1]
Loaded plugins: fastestmirror, priorities
Loading mirror speeds from cached hostfile
* rpmforge: apt.sw.be
* base: ftp.hosteurope.de
* updates: ftp.hosteurope.de
* addons: ftp.hosteurope.de
* extras: ftp.hosteurope.de
virtualmin | 951 B 00:00
virtualmin-universal | 951 B 00:00
rpmforge | 1.1 kB 00:00
base | 1.1 kB 00:00
updates | 951 B 00:00
addons | 951 B 00:00
extras | 1.1 kB 00:00
468 packages excluded due to repository priority protections

audit-libs.i386 1.7.7-6.el5_3.3 updates
audit-libs.x86_64 1.7.7-6.el5_3.3 updates
audit-libs-python.x86_64 1.7.7-6.el5_3.3 updates
clamav-db.x86_64 0.95.1-4.el5.rf rpmforge
curl.x86_64 7.15.5-2.1.el5_3.4 updates
file.x86_64 4.17-15.el5_3.1 updates
filesystem.x86_64 2.4.0-2.el5.centos base
freetype.x86_64 2.2.1-21.el5_3 updates
libselinux.i386 1.33.4-5.1.el5 base
libselinux.x86_64 1.33.4-5.1.el5 base
libselinux-devel.x86_64 1.33.4-5.1.el5 base
libselinux-python.x86_64 1.33.4-5.1.el5 base
net-snmp.x86_64 1:5.3.2.2-5.el5_3.1 updates
net-snmp-libs.i386 1:5.3.2.2-5.el5_3.1 updates
net-snmp-libs.x86_64 1:5.3.2.2-5.el5_3.1 updates
perl-DBD-Pg.x86_64 1.49-2.el5_3.1 updates
php.x86_64 5.1.6-23.2.el5_3 updates
php-cli.x86_64 5.1.6-23.2.el5_3 updates
php-common.x86_64 5.1.6-23.2.el5_3 updates
php-gd.x86_64 5.1.6-23.2.el5_3 updates
php-imap.x86_64 5.1.6-23.2.el5_3 updates
php-mbstring.x86_64 5.1.6-23.2.el5_3 updates
php-mysql.x86_64 5.1.6-23.2.el5_3 updates
php-odbc.x86_64 5.1.6-23.2.el5_3 updates
php-pdo.x86_64 5.1.6-23.2.el5_3 updates
php-pgsql.x86_64 5.1.6-23.2.el5_3 updates
php-snmp.x86_64 5.1.6-23.2.el5_3 updates
php-xmlrpc.x86_64 5.1.6-23.2.el5_3 updates
policycoreutils.x86_64 1.33.12-14.2.el5 base
popt.x86_64 1.10.2.3-9.el5 base
rpm.x86_64 4.4.2.3-9.el5 base
rpm-libs.x86_64 4.4.2.3-9.el5 base
rpm-python.x86_64 4.4.2.3-9.el5 base
wbm-virtual-server.noarch 2:3.69-1 virtualmin-universal
wbm-virtualmin-awstats.noarch 2:4.1-1 virtualmin-universal
wbm-virtualmin-svn.noarch 2:4.3-1 virtualmin-universal
wbt-virtual-server-theme.noarch 2:7.1-1 virtualmin-universal
[/code:1]

Quite a lot more than I thought. I guess I'll start next week looking to resolve those odd yum messages that prevent the update.

If you want to see them, here they are:

[code:1]
Loaded plugins: fastestmirror, priorities
Loading mirror speeds from cached hostfile
* rpmforge: apt.sw.be
* base: ftp.hosteurope.de
* updates: ftp.hosteurope.de
* addons: ftp.hosteurope.de
* extras: ftp.hosteurope.de
468 packages excluded due to repository priority protections
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package php-xmlrpc.x86_64 0:5.1.6-23.2.el5_3 set to be updated
---> Package policycoreutils.x86_64 0:1.33.12-14.2.el5 set to be updated
--> Processing Dependency: libselinux-utils for package: policycoreutils
---> Package php-odbc.x86_64 0:5.1.6-23.2.el5_3 set to be updated
---> Package wbm-virtual-server.noarch 2:3.69-1 set to be updated
---> Package wbt-virtual-server-theme.noarch 2:7.1-1 set to be updated
---> Package curl.x86_64 0:7.15.5-2.1.el5_3.4 set to be updated
---> Package audit-libs.x86_64 0:1.7.7-6.el5_3.3 set to be updated
--> Processing Dependency: clamav-server = 0.95.1-1.vm.el5 for package: clamav-server-sysv
---> Package net-snmp.x86_64 1:5.3.2.2-5.el5_3.1 set to be updated
---> Package libselinux-devel.x86_64 0:1.33.4-5.1.el5 set to be updated
---> Package libselinux.i386 0:1.33.4-5.1.el5 set to be updated
---> Package freetype.x86_64 0:2.2.1-21.el5_3 set to be updated
---> Package perl-DBD-mysql.x86_64 0:4.010-1.el5.rf set to be updated
---> Package popt.x86_64 0:1.10.2.3-9.el5 set to be updated
---> Package php.x86_64 0:5.1.6-23.2.el5_3 set to be updated
---> Package wbm-virtualmin-awstats.noarch 2:4.1-1 set to be updated
---> Package php-common.x86_64 0:5.1.6-23.2.el5_3 set to be updated
---> Package rpm-python.x86_64 0:4.4.2.3-9.el5 set to be updated
---> Package file.x86_64 0:4.17-15.el5_3.1 set to be updated
---> Package wbm-virtualmin-svn.noarch 2:4.3-1 set to be updated
---> Package php-snmp.x86_64 0:5.1.6-23.2.el5_3 set to be updated
---> Package rpm-libs.x86_64 0:4.4.2.3-9.el5 set to be updated
---> Package net-snmp-libs.i386 1:5.3.2.2-5.el5_3.1 set to be updated
---> Package libselinux.x86_64 0:1.33.4-5.1.el5 set to be updated
---> Package audit-libs.i386 0:1.7.7-6.el5_3.3 set to be updated
---> Package php-imap.x86_64 0:5.1.6-23.2.el5_3 set to be updated
---> Package php-cli.x86_64 0:5.1.6-23.2.el5_3 set to be updated
---> Package net-snmp-libs.x86_64 1:5.3.2.2-5.el5_3.1 set to be updated
--> Processing Dependency: data(clamav) for package: clamav
--> Processing Dependency: data(clamav) for package: clamav-lib
---> Package php-pdo.x86_64 0:5.1.6-23.2.el5_3 set to be updated
---> Package rpm.x86_64 0:4.4.2.3-9.el5 set to be updated
---> Package filesystem.x86_64 0:2.4.0-2.el5.centos set to be updated
---> Package audit-libs-python.x86_64 0:1.7.7-6.el5_3.3 set to be updated
---> Package clamd.x86_64 0:0.95.1-4.el5.rf set to be updated
--> Processing Dependency: clamav = 0.95.1-4.el5.rf for package: clamd
---> Package perl-DBD-Pg.x86_64 0:1.49-2.el5_3.1 set to be updated
---> Package php-pgsql.x86_64 0:5.1.6-23.2.el5_3 set to be updated
---> Package libselinux-python.x86_64 0:1.33.4-5.1.el5 set to be updated
---> Package php-gd.x86_64 0:5.1.6-23.2.el5_3 set to be updated
---> Package php-mbstring.x86_64 0:5.1.6-23.2.el5_3 set to be updated
---> Package php-mysql.x86_64 0:5.1.6-23.2.el5_3 set to be updated
---> Package clamav-db.x86_64 0:0.95.1-4.el5.rf set to be updated
--> Running transaction check
--> Processing Dependency: clamav-server = 0.95.1-1.vm.el5 for package: clamav-server-sysv
---> Package clamav-data-empty.x86_64 0:0.95.1-1.vm.el5 set to be updated
---> Package libselinux-utils.x86_64 0:1.33.4-5.1.el5 set to be updated
---> Package clamd.x86_64 0:0.95.1-4.el5.rf set to be updated
--> Processing Dependency: clamav = 0.95.1-4.el5.rf for package: clamd
--> Processing Dependency: /usr/bin/freshclam for package: virtualmin-base
--> Finished Dependency Resolution
virtualmin-base-1.0-61.rh.noarch from installed has depsolving problems
--> Missing Dependency: /usr/bin/freshclam is needed by package virtualmin-base-1.0-61.rh.noarch (installed)
clamav-server-sysv-0.95.1-1.vm.el5.x86_64 from installed has depsolving problems
--> Missing Dependency: clamav-server = 0.95.1-1.vm.el5 is needed by package clamav-server-sysv-0.95.1-1.vm.el5.x86_64 (installed)
clamd-0.95.1-4.el5.rf.x86_64 from rpmforge has depsolving problems
--> Missing Dependency: clamav = 0.95.1-4.el5.rf is needed by package clamd-0.95.1-4.el5.rf.x86_64 (rpmforge)
Error: Missing Dependency: /usr/bin/freshclam is needed by package virtualmin-base-1.0-61.rh.noarch (installed)
Error: Missing Dependency: clamav = 0.95.1-4.el5.rf is needed by package clamd-0.95.1-4.el5.rf.x86_64 (rpmforge)
Error: Missing Dependency: clamav-server = 0.95.1-1.vm.el5 is needed by package clamav-server-sysv-0.95.1-1.vm.el5.x86_64 (installed)
[/code:1]

Fri, 06/05/2009 - 11:29 (Reply to #21)
andreychek

Well, while we should get the clamav issue resolved eventually -- the packages that may be related to this current problem are:

audit*
filesystem*
libselinux*
policy*

Perhaps you could start by installing just those, rather than trying to fix the clam stuff ATM, at least to see if we can get cron working again :-)
-Eric

Fri, 06/05/2009 - 11:47 (Reply to #22)
ipsa

Ok, I ran "yum update audit* filesystem* libselinux* policy*" and they all seemed to update correctly except one:

Updating : filesystem [ 9/19]
Error unpacking rpm package filesystem-2.4.0-2.el5.centos.x86_64
error: unpacking of archive failed on file /proc: cpio: chown

I then restarted crond and the same error messages still keep being added every few minutes to /var/log/cron.

Thanks again for the help.

Fri, 06/05/2009 - 12:29 (Reply to #23)
Joe
Joe's picture

<div class='quote'>I'm not fully up to date. yum has a problem updating some clamav stuff (it seems to be looking for /usr/bin/freshclam, which is there but it's still complaining that it is missing; wouldn't mind pointer with that one either).</div>

You have conflicting yum repositories. e.g. two yum repos that provide clam packages, and those packages are not compatible with each other. You cannot do that. You must use exclude or includepkgs, or disable the troublesome repo.

I would suggest that being up to date is at least as important as your cron problem.

--

Check out the forum guidelines!

Mon, 06/08/2009 - 11:20 (Reply to #24)
ipsa

Do I need to remove ClamAV before attempting to fix this?

Do you have any pointers on how to do this? Maybe a link to a good howto or something? I'm a total yum newbie.

And how should I tell which repository is the one that I should use? (Or even which ones are in conflict)

(P.S. I think the import of this thread in the new software went wonky since everything is in a seemingly random order.)

Mon, 06/08/2009 - 18:42 (Reply to #25)
Joe
Joe's picture

Do I need to remove ClamAV before attempting to fix this?

Not if you want to keep using that set of packages. You just need to make sure you disable getting clamav from whatever repo you didn't install from to start with. The problem here is not that you have clamav installed, it is that you are trying to update it from multiple sources.

Do you have any pointers on how to do this? Maybe a link to a good howto or something? I'm a total yum newbie.

It's been discussed a bunch in the forums and ticket tracker. This is one that sort of covers the details.

https://www.virtualmin.com/node/2770

In short, you just need to edit either the Virtualmin or the rpmfusion/rpmforge/whatever repository file (/etc/yum.repos.d/something.rpm) and add exclude=* to the relevant repository sections. If you already have our package installed (has "vm" in the version string), then you'd disable getting clamav from the other repo. If it's from the other repo, you'd disable it from our repo.

I would also recommend you not go adding software repositories to yum all willy-nilly without understanding what you're doing. It can be very dangerous. You're effectively giving root access to your system to anyone you trust to provide packages for you. Adding a repository in yum is serious business.

And how should I tell which repository is the one that I should use? (Or even which ones are in conflict)

If you don't know, then I'd say only use the CentOS official repositories, and ours. yum repos are serious business. Using third party repositories without understanding is a recipe for disaster.

(P.S. I think the import of this thread in the new software went wonky since everything is in a seemingly random order.)

Nah, default sort order is just goofy. I'll fix it.

--

Check out the forum guidelines!

Tue, 06/09/2009 - 13:53 (Reply to #26)
ipsa

Thanks for the pointers. I inherited this server when I went to a new job so I know next to nothing about how it was setup by the previous guy.

I'm normally a debian/ubuntu guy so I'm not wholly unfamiliar with repositories but yum is a new beast I haven't taken the time to master yet.

I'll try to fix this and I'll let you know how it turns out.

(Thanks for fixing the thread order too!)

ETA: Well, that was easy. I just renamed "rpmforge.repo" to "rpmforge.repo.disabled" in "/etc/yum.repos.d" and poof, the problem went away.

There's still this though:

Downloading Packages:
filesystem-2.4.0-2.el5.centos.x86_64.rpm                 | 117 kB     00:00    
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Updating       : filesystem                                        [1/2]
Error unpacking rpm package filesystem-2.4.0-2.el5.centos.x86_64
error: unpacking of archive failed on file /proc: cpio: chown

Google has been of little to no help on that one so far. Still, progress! :)

Tue, 06/09/2009 - 13:59 (Reply to #27)
andreychek

So this is the error you're seeing:

"error: unpacking of archive failed on file /proc: cpio: chown"

Does anything appear after the word "chown"?

Also, what's the output of the command:

/usr/sbin/getenforce

Tue, 06/09/2009 - 14:05 (Reply to #28)
ipsa

No, nothing after chown but a blank line. Here's the whole thing:

-bash-3.2# yum update
Loaded plugins: fastestmirror, priorities
Loading mirror speeds from cached hostfile
* base: ftp.halifax.rwth-aachen.de
* updates: ftp.halifax.rwth-aachen.de
* addons: ftp.halifax.rwth-aachen.de
* extras: ftp.halifax.rwth-aachen.de
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package filesystem.x86_64 0:2.4.0-2.el5.centos set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
Package           Arch          Version                      Repository   Size
================================================================================
Updating:
filesystem        x86_64        2.4.0-2.el5.centos           base        117 k

Transaction Summary
================================================================================
Install      0 Package(s)        
Update       1 Package(s)        
Remove       0 Package(s)        

Total download size: 117 k
Is this ok [y/N]: y
Downloading Packages:
filesystem-2.4.0-2.el5.centos.x86_64.rpm                 | 117 kB     00:00    
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Updating       : filesystem                                        [1/2]
Error unpacking rpm package filesystem-2.4.0-2.el5.centos.x86_64
error: unpacking of archive failed on file /proc: cpio: chown

Updated: filesystem.x86_64 0:2.4.0-2.el5.centos
Complete!
-bash-3.2#

That command outputs "Disabled".

BTW, I just realised that my previous message might have been confusing: the yum update problem went away, the cron problem is still alive and kicking. Sorry.

Thanks again, you guys are fantastic!

Tue, 06/16/2009 - 11:07
ipsa

Hi,

While the yum updating problem has been fixed (mostly, "filesystem" still won't update for some reason), "crond" still outputs errors to "/var/log/crond" every few minutes and therefore backups aren't triggered when scheduled.

Now, this isn't the end of the world since I'm using my local box' cron to ssh into the server and trigger the backups but it isn't great either.

SELinux is still disabled. Any other ideas of what to do to get cron working correctly on this server?

Thanks.

Tue, 06/16/2009 - 18:13 (Reply to #30)
Joe
Joe's picture

Googling on some of your errors turns up the following:

http://hostechs.com/2008/07/cron-error-failed-to-open-pam-security-session/

Which seems maybe promising?

--

Check out the forum guidelines!

Topic locked