GenericAgent: can't open .../DynamicField/....

[massimobianchi]

Hello,
I am getting this error, daily, from the cron job:

ERROR: OTRS-otrs.GenericAgent.pl-10 Perl: 5.10.1 OS: linux Time: Sat Apr 14 03:40:02 2012

Message: Can't open '/opt/otrs/var/tmp/CacheFileStorable/DynamicField/bfdc5f1e460c58d65e1512de4025075e': No such file or directory

Traceback (8588):
Module: Kernel::System::Main::FileRead (v1.63) Line: 337
Module: Kernel::System::Cache::FileStorable::Get (v1.9) Line: 117
Module: Kernel::System::Cache::Get (v1.21) Line: 157
Module: Kernel::System::DynamicField::DynamicFieldGet (v1.54) Line: 291
Module: Kernel::System::DynamicField::DynamicFieldListGet (v1.54) Line: 960
Module: Kernel::System::GenericAgent::new (v1.81) Line: 117
Module: /opt/otrs/bin/otrs.GenericAgent.pl (v1.6) Line: 89

I checked at OS level, the file exist, and is readable by the otrs user (owner of cron)

file bfd... content is:
##############################

2012-02-28 14:26:01
ChangeTime2
CreateTime
FieldOrderImpact
ObjectType7%)

13344132024%)

##############################

Questions:
1) what is this file ?
2) how cai I link it to the dynamicfiled in otrs ?
3) since it's a cache, is it safe to delete it and the other files in the directory ?

Kind regards,
Massimo

[tc7]

I too am seeing the same problem.
I have just upgraded from 3.0.11 --> 3.1.4

I now get a nightly error from a cron job, eg:
ERROR: OTRS-otrs.GenericAgent.pl-10 Perl: 5.10.1 OS: linux Time: Wed May 9 18:40:01 2012

Message: Can't open '/opt/otrs/otrs_one/var/tmp/CacheFileStorable/DynamicField/f3b7e10730fb6c9cab5ae0e7f7e034f3': No such file or directory

Traceback (14628):
Module: Kernel::System::Main::FileRead (v1.63) Line: 337
Module: Kernel::System::Cache::FileStorable::Get (v1.9) Line: 117
Module: Kernel::System::Cache::Get (v1.21) Line: 157
Module: Kernel::System::DynamicField::DynamicFieldGet (v1.56) Line: 297
Module: Kernel::System::DynamicField::DynamicFieldListGet (v1.56) Line: 965
Module: Kernel::System::GenericAgent::new (v1.81) Line: 117
Module: /opt/otrs/otrs_one/bin/otrs.GenericAgent.pl (v1.6) Line: 89

But if I check the file it exists and is accessible by the otrs user.
Is there a fix for this error?

[micshi]

Hope you report it to bugs.otrs.org.

micshi

[tc7]

I've raised this as bug 8470
http://bugs.otrs.org/show_bug.cgi?id=8470

[gjs]

Interestingly following this topic and bug report, having the same issue.

[subo]

I've raised this as bug 8470
http://bugs.otrs.org/show_bug.cgi?id=8470

Hi!
I've the same problem. But this problem only shows up on a migrated system (3.0.11 to 3.1.5), not on a fresh installation(3.1.5).

Greetings,
-Subo

[hardoverflow]

I have the same problem.

[schaffel]

We have this Problem too

[crythias]

Relevant code:

Code: Select all

335	    # return if file can not open
336	    if ( !open $FH, $Mode, $Param{Location} ) {
337	        $Self->{LogObject}->Log(
338	            Priority => 'error',
339	            Message  => "Can't open '$Param{Location}': $!",
340	        );
341	        return;
342	    }

There's not much to debug. It's not enough to say, "Yes it does exist", but check path and case sensitivity.

GenericAgent.pl runs otrs/var/cron/cache

Code: Select all

13	20 0 * * 0  $HOME/bin/otrs.DeleteCache.pl --expired >> /dev/null
14	30 0 * * 0  $HOME/bin/otrs.LoaderCache.pl -o delete >> /dev/null

The short answer is that the file requested is trying to be deleted but cannot. Check permissions and if that's not good enough, run the commands yourself from a command line:

Code: Select all

bin/otrs.DeleteCache.pl --expired
bin/otrs.LoaderCache.pl -o delete

If all else fails, delete the file from Cache manually. It's in a folder called "tmp", anyway, right?

DISCLAIMER: Don't just delete files because they're erroring, but in this case, it has a high likelihood of being okay to delete. Backup your filesystem before making changes to files.

[svs]

Hi,

same issue here, a migrated OTRS as well.

There's not much to debug. It's not enough to say, "Yes it does exist", but check path and case sensitivity.

Everything is correct: the path, the case sensitivity and also the permissions. The file, which is mentioned in the email, exists.

GenericAgent.pl runs otrs/var/cron/cache

Code: Select all

13	20 0 * * 0  $HOME/bin/otrs.DeleteCache.pl --expired >> /dev/null
14	30 0 * * 0  $HOME/bin/otrs.LoaderCache.pl -o delete >> /dev/null

The short answer is that the file requested is trying to be deleted but cannot. Check permissions and if that's not good enough, run the commands yourself from a command line:

Code: Select all

bin/otrs.DeleteCache.pl --expired
bin/otrs.LoaderCache.pl -o delete

I have executed the commands manually and there were no error message. Everything is working properly. Also the configuration of the cron doesn't match the interval, in which the error mails are sent. The cron job is executed once a week. The error mail comes every day several times.

Which sense do these cache files have? Of course I could just delete them, but what is the purpose of this particular files for dynamic fields?

It's really strange the OTRS does not react on this issue. It exists since version 3.1 and when I take a look at the bug report, it's still stated as "New".

Greets,
svs

[crythias]

is there any possibility you have a dev or test box trying to mimic your live data?

[svs]

Not with cron running on the dev system...

[crythias]

Start with determining what *EXACT* cron job is sending you the message. You've already determined that the job is blind to the directory structure. Next step is to determine what cron job is doing this, on what machine, and what task it is calling.

[svs]

I'm not sure, but I think the message is telling me the taks/job, which causing the error:

Code: Select all

ERROR: OTRS-otrs.GenericAgent.pl-69 (...)

Message: Can't open '(...)/DynamicField/(...)': File or Directory not found.

Traceback (25627): 
  Module: Kernel::System::Main::FileRead (v1.63) Line: 337
  Module: Kernel::System::Cache::FileStorable::Get (v1.9) Line: 117
  Module: Kernel::System::Cache::Get (v1.21) Line: 157
  Module: Kernel::System::DynamicField::DynamicFieldGet (v1.56.2.2) Line: 272
  Module: Kernel::System::DynamicField::DynamicFieldListGet (v1.56.2.2) Line: 940
  Module: Kernel::System::GenericAgent::new (v1.81) Line: 117
  Module: (...)/bin/otrs.GenericAgent.pl (v1.6) Line: 89

Seems to be the following line in otrs.GenericAgent.pl

Code: Select all

$CommonObject{GenericAgentObject} = Kernel::System::GenericAgent->new(
    %CommonObject,
    Debug        => $Opts{d},
    NoticeSTDOUT => 1,
);

[massimobianchi]

Maybe I find a solution.

Try: /opt/otrs/bin/otrs.DeleteCache.pl (if on linux).

After that I had no longer the problem.

[svs]

Nice idea, but I'm doing this during every upgrade of OTRS without any effect until now. After the last upgrade I thought that this issue is fixed, as there were an entry in the release notes, which let me hope that this issue is fixed. After the upgrade, there were no more error message...for two days. After two days the emails came back.


svs

[crythias]

check for duplicate entries in cron
crontab -l -u otrs

make sure cron isn't running this job as both otrs user and root or another user that did the install.
check /var/spool/cron/crontabs as root and double-verify the job(s) aren't running as another user or twice:
cd /var/spool/cron/crontabs
grep otrs *

make sure cron jobs aren't duplicated in otrs/var/cron (remove or mkdir backup; mv *dist backup/)

restart cron
cd /opt/otrs
bin/Cron.sh stop otrs
bin/Cron.sh start otrs

[sewellj]

Just to bump crythias post from 10 Aug 2012, 06:14

We have been having these reports from our cron as well. There don't seem to be any actual problems caused by this but we would like to clean it up if possible.

We looked into whether there were duplicates of this job in cron, and there may be some. From crontab -l -u otrs:

*/5 * * * * $HOME/bin/otrs.GenericAgent.pl >> /dev/null
*/10 * * * * $HOME/bin/otrs.GenericAgent.pl -c db >> /dev/null

They are running different arguments, but with the every 5 and every 10 they will potentially conflict every 10 minutes.

Should we re-think the timing of these so there are no conflicts?


-James

[crythias]

also grep otrs /etc/passwd and check $HOME directory path

[sewellj]

/bin/false

Should this be a proper shell?


-James

[sewellj]

Home dir is /opt/otrs which in the install location on our system

[rodneyyeo]

Check log for error log entries... "You have more error log entries: Can't open '/opt/otrs/var/tmp/CacheFileStorable/DynamicField/8651eb3fbf23669fa722046d84b46d5e': No such file or directory"



The "$HOME" is set at environment variable to "/root" on CentOS 6.3.

I manually change at Cron job for OTRS user to the below.

#su otrs



Make sure to replace all variable string for "$HOME" to "/opt/otrs" in cron

#crontab -e

# delete expired cache weekly (Sunday mornings)
20 0 * * 0 /opt/otrs/bin/otrs.DeleteCache.pl --expired >> /dev/null
30 0 * * 0 /opt/otrs/bin/otrs.LoaderCache.pl -o delete >> /dev/null

Rodney

[jojo]

the $HOME of the otrs user should noit be /root

The cronjobs for OTRS need to be run as otrs user, not as root