log file corruption on simultaneous script execution? Never. But I don't do millions of transactions per minute, either, and neither does OTRS. I would assume that the likelihood of this being simultaneous *enough* to cause a problem would be so infrequent as to to be statistically negligible, and even then, I would hope and expect file locking during the time required to append what amounts to 100 bytes (?) would properly be handled. Even more so, since the logs are handled by the same method that the entire OS uses, and I'm reasonably certain few people are concerned about simultaneous clobbering of logging files. At least, it's not high on most people's priority list because it's just not something that's been often evidenced. Further, a journalling file system may mitigate this as well, but I'm not in a place to say it couldn't happen. It's just not the thing I should spend an entire thread discussing unless it has.
Thanks for the previous answers.
Have you experienced otrs.log file corruption or any other weird results resulting from two Perl processes (one invoked from cron and one apache via mod_perl) trying to execute simultaneously the script implementing OTRS's log module for the purpose of logging a message to otrs.log?
I need more hands on experience to determine what will get logged to apache's / cron's logs. I'm thinking errors arising from syntactically flawed Perl scripts would get logged there.
As far as Generic Agent jobs go... I can see otrs.log contains entries for executions of jobs according with Generic Agent jobs' own schedule (~independent of cron) but there are no entries about what each execution did (I tried a simple job that closes some tickets, it worked but there was no mention in the log about the tickets getting closed). Is there any way to log such details by increasing OTRS's log level or something similar?
/bogdan
P.S: Sorry for not being able to respond quicker, there's a hefty time difference between us, I think (I'm in Bucharest, Romania, Eastern Europe)On Wed, Oct 17, 2012 at 6:08 PM, Gerald Young <crythias@gmail.com> wrote:
Apache errors are apache errors. These could be anything that apache doesn't understand. OTRS application based logging happens in otrs logs via the method described. The front end interface to the application has different things that it checks, and may be out of the scope of what OTRS knows, and vice versa. It is entirely possible that OTRS can receive and manage tickets with all other events, filters, and cron jobs executing without apache running. Whether Agents can interact with tickets is a different issue, but the provider of the web interface (apache, iis, nginx, etc) and OTRS may not know anything about the other.Re: logging from cron: the fact that a job runs or not is logged via the appropriate logging method of the cron service. This only tells you that it tried to run it.Anything that the job does to otrs, if the job uses API and the API logs something, will be handled via OTRS's syslog facility. As with any other service, the provider of the service and OTRS itself may be agnostic to anything the service does. OTRS won't know the cron job has run. It will report in its syslog facility (see my link) on what it knows in the application. Timestamps in OTRS's syslog should concur with the cron job being run, but to OTRS, it is immaterial that the job is being run by cron or by command line. The cron service has no clue that it is running an OTRS job, on its own, but may report on errors if such is configured in the crontab.On Wed, Oct 17, 2012 at 10:52 AM, Bogdan Iosif <bogdan.iosif@gmail.com> wrote:
I get the fact that on *nix systems, otrs.log is likely replaced by syslog.
Apache's error.log, I'm most confused about, especially in relationship with otrs.log. Will errors commonly appear in both logs in different form or is my initial (3.2.1) assumption generally true in that an error usually appears in apache's error log if it's missed by OTRS's code.
Also, I saw references in mailing list entries / forums pointing users to check OTRS's "console log". I don't know what that usually means. Apache's error.log, otrs.log/syslog, both or something else?
Logging from jobs invoked via cron[w] are another source of mystery. Do the jobs coming with OTRS by default perform their logging to syslog/otrs.log or do they do it by using cron's log? Auditing some kind of output from Generic Agent's executions is of special interest to me because I hate running that without being able to see exactly what it did or did not do.
Thanks,
bogdanOn Wed, Oct 17, 2012 at 5:06 PM, Gerald Young <crythias@gmail.com> wrote:
I want to plug this link ... http://forums.otterhub.org/viewtopic.php?f=60&t=168262 through 4 are application/operating system specific file locations, but much of what you've described appears to be accurate.In *general*, the only truly relevant logs are otrs.log/syslog (per the link above, more information) and apache logs.On the other hand, application specific logs would troubleshoot problems with, for instance, email or cron jobs not running. Much of the time, these issues do not relate to problems with OTRS, but with the service OTRS calls.
TicketCounter.log is also in var/log/ and is relevant in different ways to different ticket numbering schemes.On Wed, Oct 17, 2012 at 9:46 AM, Bogdan Iosif <bogdan.iosif@gmail.com> wrote:
---------------------------------------------------------------------Hi,
What is the big picture of an OTRS instance's logging subsystem[s]?
Please validate / complete the following statements or maybe paint your own picture or point me to a doc source (i failed to Google my way to one):
- (1) files: %OTRS_HOME%\var\logs\*.log
- (1.1) "otrs.log"
- (1.1.1) Are these statements correct? : "otrs.log" is the main log file where entries are written only via the "Kernel::System::Log" core module. Investigation for most non-trivial OTRS errors should start by looking in "otrs.log".
- (1.2) "SchedulerERR*.log" / "SchedulerOUT*.log"
- (1.2.1) What purpose do these files serve?
- (1.3) Are there other log files commonly found in this folder?
- (2) GUI: ADMIN -> "System Log"
- (2.1) Are these statements correct? : "otrs.log" from (1.1) is exposed in this GUI on *nix installations but not on Windows http://doc.otrs.org/3.1/en/html/adminarea-system-log.html
- (3) files: %APACHE_HOME%\logs\*.log
- (3.1) "access.log"
- (3.1.1) Are these statements correct? : Not very interesting for OTRS error analysis. Documented here http://httpd.apache.org/docs/2.2/logs.html#accesslog
- (3.2) "error.log"
- (3.2.1) Are these statements correct? : When OTRS crashes really bad, this is the log to look at. "Console" log for mod_perl??? Documented here http://httpd.apache.org/docs/2.2/logs.html#errorlog
- (3.3) Are there other log files commonly found in this folder?
- (4) files: %CRONW_HOME%\logs\*.log
- (4.1) "cronw.log"
- (4.1.1) Are these statements correct? : Specific to Windows. Cronw writes to this log, depending on its logging level, when it starts up, reloads crontab or executes various entries in crontab
- (4.1.1) Since Generic Agent jobs are run from cronw, will errors encountered by these jobs be written to this log? If not, then where? Any relationship to (1.2)? Is it possible to log some kind of output from Generic Agent jobs for audit purposes? If so, how?
- (4.2) Are there other log files commonly found in this folder?
Looks like a quiz but I was just trying to make it easy to answer to a particular question.
Thanks,
Bogdan
P.S: I'm running v3.1.10 on Windows with the configuration deployed by the Windows installer OTRS package (Apache/StrawberryPerl/mysql)
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs