Per Jessen said the following on 09/28/2012 09:50 AM:
Does anyone here have any thoughts on the matter? To me, it's clearly a regression and wrong - the executable name is logged as /USR/SBIN/CRON, which doesn't exist:
ls -l /USR/SBIN/CRON ls: cannot access /USR/SBIN/CRON: No such file or directory
I discovered it by accident when I upgraded a system to 12.2, but it's been like this for 11.4 and 12.1.
I think you are missing a point here. "A" point, I say, perhaps not "THE" point, but ... The "/USR/SBIN/CRON" is where its announcing the service reporting. The executable - what cron is running, is in lower case. The mistake here is not that CRON is shouting its name but that its shouting its path. Other entries in syslog look like nmbd[2733]: Got SIGHUP dumping debug info. and pulseaudio[7486]: [pulseaudio] main.c: Daemon startup failed. By comparison, my mailhub server, which runs Mandriva, shouts like this CROND[6594]: (anton) CMD ((fetchmail -q; sleep 5; fetchmail -d 600)) But the whole thing is inconsistent. When I list and then edit my crontab file it is sysloged like this crontab[6550]: (anton) LIST (anton) crontab[6553]: (anton) BEGIN EDIT (anton) crontab[6553]: (anton) REPLACE (anton) crontab[6553]: (anton) END EDIT (anton) crond[1844]: (anton) RELOAD (/var/spool/cron/anton) So yes, having "/USR/SBIN/CRON" is inconsistent. Personally I think the "uppercase path" argument isn't the one to make. That I see nothing else in my syslog that "shouts" and nothing else where the reporting server tells its path (rather than the path of what it is using as an argument). I would base the bug report and request for change on that and not on the fact that "/USR/SBIN/CRON" doesn't exist. -- All warfare is based on deception. There is no place where espionage is not used. Offer the enemy bait to lure him. Sun-Tzu -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org