Apr 5 01:20:00 my_server_name crond[19123]: (username) RELOAD (cron/username)
Apr 5 01:20:00 my_server_name crond[19123]: ( tmp.7440) ORPHAN (no passwd entry)
Apr 5 01:20:00 my_server_name crond[19123]: (tmp.16094) ORPHAN (no passwd entry)
Apr 5 01:20:00 my_server_name crond[19123]: (tmp.16095) ORPHAN (no passwd entry)
Apr 5 01:28:00 my_server_name crond[19123]: (username) RELOAD (cron/username)
Apr 5 01:28:00 my_server_name crond[19123]: (tmp.7440) ORPHAN (no passwd entry)
Apr 5 01:28:00 my_server_name crond[19123]: (tmp.16094) ORPHAN (no passwd entry)
Apr 5 01:28:00 my_server_name crond[19123]: ( tmp.16095) ORPHAN (no passwd entry)
Apr 5 01:20:00 my_server_name crond[19123]: ( tmp.7440) ORPHAN (no passwd entry)
Apr 5 01:20:00 my_server_name crond[19123]: (tmp.16094) ORPHAN (no passwd entry)
Apr 5 01:20:00 my_server_name crond[19123]: (tmp.16095) ORPHAN (no passwd entry)
Apr 5 01:28:00 my_server_name crond[19123]: (username) RELOAD (cron/username)
Apr 5 01:28:00 my_server_name crond[19123]: (tmp.7440) ORPHAN (no passwd entry)
Apr 5 01:28:00 my_server_name crond[19123]: (tmp.16094) ORPHAN (no passwd entry)
Apr 5 01:28:00 my_server_name crond[19123]: ( tmp.16095) ORPHAN (no passwd entry)
and somehow there are a lot of crond processes:
# ps aux|grep -i cron
root 18855 0.0 0.0 4100 1844 ? D 01:16 0:00 CROND
root 18856 99.9 0.0 4100 1844 ? R 01:16 2:07 CROND
root 18922 0.0 0.0 4100 1844 ? D 01:17 0:00 CROND
root 18923 99.9 0.0 4100 1844 ? R 01:17 1:08 CROND
root 19123 0.0 0.0 4104 1828 ? S 01:18 0:00 crond
root 19863 0.0 0.0 4104 1844 ? S 01:19 0:00 CROND
root 19917 0.0 0.0 4104 1844 ? S 01:20 0:00 CROND
Read more...root 18855 0.0 0.0 4100 1844 ? D 01:16 0:00 CROND
root 18856 99.9 0.0 4100 1844 ? R 01:16 2:07 CROND
root 18922 0.0 0.0 4100 1844 ? D 01:17 0:00 CROND
root 18923 99.9 0.0 4100 1844 ? R 01:17 1:08 CROND
root 19123 0.0 0.0 4104 1828 ? S 01:18 0:00 crond
root 19863 0.0 0.0 4104 1844 ? S 01:19 0:00 CROND
root 19917 0.0 0.0 4104 1844 ? S 01:20 0:00 CROND
after some googling, i found out this error normally because of the user doesn't exist in /etc/passwd
but the user is exist in the /etc/passwd, so should be no problem then!
back to google & google & google again and the solution is - if your servers are integrated with LDAP or AD you better make sure you are using nscd service as well.
in my case we are using AD but the nscd process is not running, somehow dead! start the nscd service & the cron jobs are working fine now.
lesson learnt - make sure all the processes that you expect to be running, all are running well.
in case you not sure what nscd is, here is the man page:
# man nscd
nscd(8) nscd(8)
NAME
/usr/sbin/nscd - name service cache daemon
DESCRIPTION
Nscd is a daemon that provides a cache for the most common name service
requests. The default configuration file, /etc/nscd.conf, determines
the behavior of the cache daemon. See nscd.conf(5).
Nscd provides cacheing for the passwd(5), group(5), and hosts(5)
databases through standard libc interfaces, such as getpwnam(3),
getp-wuid(3), getgrnam(3), getgrgid(3), gethostbyname(3), and others.
Each cache has a separate TTL (time-to-live) for its data; modifying the
local database (/etc/passwd, and so forth) causes the cache to become
invalidated within fifteen seconds. Note that the shadow file is
specifically not cached. getspnam(3) calls remain uncached as a
result.
nscd(8) nscd(8)
NAME
/usr/sbin/nscd - name service cache daemon
DESCRIPTION
Nscd is a daemon that provides a cache for the most common name service
requests. The default configuration file, /etc/nscd.conf, determines
the behavior of the cache daemon. See nscd.conf(5).
Nscd provides cacheing for the passwd(5), group(5), and hosts(5)
databases through standard libc interfaces, such as getpwnam(3),
getp-wuid(3), getgrnam(3), getgrgid(3), gethostbyname(3), and others.
Each cache has a separate TTL (time-to-live) for its data; modifying the
local database (/etc/passwd, and so forth) causes the cache to become
invalidated within fifteen seconds. Note that the shadow file is
specifically not cached. getspnam(3) calls remain uncached as a
result.
4 comments:
Thanks for posting this.. it was very helpful!
This got me on the right track, but didn't solve my issue. After a bit of googling myself I found that just restarting crond solved the issue - nscd didn't help at all.
I am using LDAP, not AD, so worth a shot if you hit this issue.
Thanks Jesse! my experience was the same... restarting crond was the ticket!
Hi,
in my case, the restart of cron didn't helped - the cron job was runnig exactly one time. After that, the error message was back in syslog.
I (re-)installed the nscd and the problem was gone.
But strange was, some crontabs of the (LDAP-)users was working and some not... Crazy!
Post a Comment