Tomcat not logging to catalina.out after logrotation in linux
how to load log in catalina.out file
I used following configuration file :
/usr/tomcat7/logs/catalina.out{
daily
copytruncate
create 664 root root
dateext
rotate 4
compress
}
Please help me
Source : https://dzone.com/articles/how-rotate-tomcat-catalinaout
/var/log/tomcat/catalina.out {
copytruncate daily rotate 7 compress missingok size 5M }
About the above configuration:
Make sure that the path /var/log/tomcat/catalina.out above is adjusted to point to your tomcat’s catalina.out
daily - rotates the catalina.out daily
rotate – keeps at most 7 log files
compress – compressesthe rotated files
size – rotates if the size of catalina.out is bigger than 5M
You don’t need to do anything else.
Also you can check a similar question
catalina.out rolling with Tomcat 6.0
Related
How do you change the default location of where your data is kept under Solr.
On an AWS setup everything I create goes into /var/solr/data
In what config file is this default location stored?
I'd like to point it at the /data directory which is a 100GB mounted hard drive.
Aside from editing each solrconfig.xml for each collection (or index) there is a work around that I've come up with in past installations.
Instead of editing 4 files to point to the new location, it is easier to simply "trick" SOLR into storing on your mounted drive using a symlink.
You will point your SOLR directory to your mounted drive:
/var/solr/data -> /data/whatever/directory
Copy your SOLR files:
cp /var/solr/data /data/whatever/directory
Back up your current data:
mv /var/solr/data/ /var/solr/data_backup
Create you symink (target -> symlink):
ln -s /data/whatever/directory /var/solr/data
After all is said and done, you, probably need to repair permissions, setting ownership to SOLR and ensuring that the linking worked correctly. Inside the /var/solr directory .. You can run a ls -lah and you should be able to see whether the link is correctly routed. If it is not, it'll be highlighted in red on most Debian systems. It should look something like:
lrwxrwxrwx 1 solr solr 31 Apr 30 2021 data -> /data/whatever/directory
Once all finished up .. Restart the SOLR service and re-index your collections.
Since I upgraded my Gradle build to deploy my App Engine application with SDK 1.9.46, I get deployment conflict messages, like the one below.
Beginning interaction for module admin...
0% Created staging directory at: '/var/folders/m8/6z4h4k2x11s3whxrqmd79lym0000gn/T/appcfg2292422843793738444.tmp'
5% Scanning for jsp files.
8% Generated git repository information file.
20% Scanning files on local disk.
25% Scanned 250 files.
28% Scanned 500 files.
31% Scanned 750 files.
33% Scanned 1000 files.
34% Initiating update.
Nov 13, 2016 11:11:41 AM com.google.appengine.tools.admin.AbstractServerConnection send1
WARNING: Error posting to URL: https://appengine.google.com/api/appversion/create?module=admin&app_id=the-outdoor-game&version=dev&
409 Conflict
There is an operation pending for this application: AppLock held for "Updating engine_version_id='dev' within engine_id='default'." acquired by Peter.Fortuin at 2016-11-13 09:15:05.482616 GMT. Please wait and try again or use 'appcfg rollback' to attempt to cleanly abort the current operation.
This is try #0
A rollback if not solving the problem. The only thing that seems to work is downgrading the App Engine SDK to 1.9.44. But that gives me other problems that I don't want to solve.
Anybody has any idea how to solve this? Can it be that this is a bug in the 1.9.46 SDK? Anybody else seeing the same thing?
I have resolved this problem by changing 'service' to 'module' in appengine-web.xml of my module.
See https://github.com/GoogleCloudPlatform/gradle-appengine-plugin/issues/268 for more information.
When trying to deploy my application:
appcfg.py update --oauth2 .
I'm getting:
PM Rolling back the update.
Error 400: --- begin server output ---
Max number of files and blobs is 10000.
--- end server output ---
How do I solve this?
You "solve" it by having less files deployed when you deploy your project. You have a few choices.
You can use Skipfiles in your app.yaml to exclude some files from being deployed:
skip_files:
- ^(.*/)?#.*#$
- ^(.*/)?.*~$
- ^(.*/)?.*\.py[co]$
- ^(.*/)?.*/RCS/.*$
- ^(.*/)?\..*$
You might want to, for example, exclude .readme files, compiled python files etc.
Or you can use ZipImport and compress your python packages and they will be unzipped on the fly during import.
Or if you are also uploading lots of static assets, put them in a bucket instead as the other answer suggests.
Looks like you are hitting this quota: https://cloud.google.com/appengine/docs/quotas#Deployments
Could you shift many of your files to Cloud Storage?
When I start debugging the process stays there at 57% and says "waiting for XDebug session".
This is a duplicate post on StackOverFlow, but I tried all the answers, nothing worked.
It was working fine until before two days. I don't know what went wrong.
Having used Eclipse to launch xdebug sessions in Firefox for ever now, all of a sudden 23/4/2013 it would not launch xdebug using Firefox. It gave me the launch 57% and hang problem.
It was quite happy to launch xdebug sessions in IE/Chrome/Safari/Opera but not Firefox.
The only thing I changed around this time was I upgrades my java runtime to 1.7.0_21 from a previous version ( cannot remember which but I did jump more than one release so it was probably 1.7.0_19 )
I took a look at the project log file, Check your projects workspace folder for a subfolder called .metadata where there should be a .log file, there is one of these for each project so be sure you are looking at the correct one.
This is what was in mine:
!SESSION 2013-04-23 11:06:21.238
----------------------------------------------- eclipse.buildId=M20130204-1200 java.version=1.7.0_21
java.vendor=Oracle Corporation BootLoader constants: OS=win32,
ARCH=x86, WS=win32, NL=en_GB Command-line arguments: -os win32 -ws
win32 -arch x86
!ENTRY org.eclipse.ui.browser 4 0 2013-04-23 11:07:32.584 !MESSAGE
Launching C:\Program Files\Mozilla Firefox\firefox.exe has failed.
!STACK 0 java.io.IOException: Cannot run program "C:\Program":
CreateProcess error=2, The system cannot find the file specified at
java.lang.ProcessBuilder.start(Unknown Source) at
java.lang.Runtime.exec(Unknown Source) at
java.lang.Runtime.exec(Unknown Source) at
java.lang.Runtime.exec(Unknown Source) at
org.eclipse.ui.internal.browser.browsers.MozillaBrowser$BrowserThread.openBrowser(MozillaBrowser.java:94)
at
org.eclipse.ui.internal.browser.browsers.MozillaBrowser$BrowserThread.run(MozillaBrowser.java:165)
Caused by: java.io.IOException: CreateProcess error=2, The system
cannot find the file specified at java.lang.ProcessImpl.create(Native
Method) at java.lang.ProcessImpl.(Unknown Source) at
java.lang.ProcessImpl.start(Unknown Source) ... 6 more
Because I saw this line
java.io.IOException: Cannot run program "C:\Program": CreateProcess error=2,
It made me thinks that for some reason java could no longer cope with folder names with spaces in them (very strange), so I changed the eclipse preferences and used the 8.3 naming convension C:\PROGRA~1\MOZILL~1\firefox.exe
Now it launches the xdebug session again!!
This is very strange as it does not seem to have problems with
C:\Program Files\Opera\opera.exe OR
C:\Program Files\Safari\Safari.exe OR
C:\Program Files\Internet Explorer\iexplore.exe
So all I can think of is that it does not like 2 folder names with spaces in them for some obsqure reason, because it wont launch firefox from C:\Program Files\Mozilla Firefox\firefox.exe
I assume it launches IE from a similiar folder named address as it is the default browser on this system.
Anyhow, the solution for me was to change the eclipse preferences ->General -> Web Browser -> Firefox
to use the 8.3 DOS directory naming convension.
Hope this helps
riggsfolly's analysis and solution are both correct, however for some reason my eclipse would not allow me to use the DOS 8.3 naming convention. As an alternative for those who run into the same issue you can try the following:
Create a parallel folder structure but do it without spaces (eg. "C:\ProgramFiles86\MozillaFirefox\")
Download and install firefox, using the custom installation options to install to your new 'spaceless' directory
In eclipse preferences ->General -> Web Browser: Make a new entry (eg. "Firefox2") and point it at your new installation (eg. C:\ProgramFiles86\MozillaFirefox\firefox.exe").
Finishing touch - use Mozilla Sync between the two browsers so you don't have to worry about outfitting your new Firefox.
And the easiest way I used to find out the 8.3 compatible windows path of Mozilla Firefox is as below.
C:\>dir .* /x
Volume in drive C has no label.
Volume Serial Number is XXXX-XXXX
Directory of C:\
File Not Found
C:\>dir *.* /x
Volume in drive C has no label.
Volume Serial Number is XXXX-XXXX
Directory of C:\
07/14/2009 08:50 AM <DIR> PerfLogs
04/01/2013 07:32 PM <DIR> PROGRA~1 Program Files
05/14/2013 01:50 PM <DIR> PROGRA~2 Program Files (x86)
01/17/2013 01:43 PM <DIR> Users
05/12/2013 05:46 AM <DIR> Windows
C:\>cd PROGRA~2
C:\PROGRA~2>dir *.* /x
Volume in drive C has no label.
Volume Serial Number is XXXX-XXXX
Directory of C:\PROGRA~2
05/14/2013 01:50 PM <DIR> .
05/14/2013 01:50 PM <DIR> ..
05/14/2013 01:50 PM <DIR> COMMON~1 Common Files
03/05/2013 10:50 AM <DIR> Google
07/14/2009 11:07 AM <DIR> INTERN~1 Internet Explorer
04/19/2013 06:03 PM <DIR> Java
04/14/2013 10:16 PM <DIR> MOZILL~1 Mozilla Firefox
04/15/2013 10:57 AM <DIR> MOZILL~2 Mozilla Maintenance Service
C:\PROGRA~2>cd MOZILL~1
C:\PROGRA~2\MOZILL~1>
I had a similar problem. mine stayed at 72%. I solved my issue by setting
xdebug.mode = debug
in the php.ini file.
I restarted the apache server now it works fine.
In addition to RiggsFolly's life-saving solution, maybe the following is useful for anyone.
Issue 1: different path on 32 bits and 64 bits Windows 7
On 32 bits Windows 7, the path is:
C:\PROGRA~1\MOZILL~1\firefox.exe
On 64 bits Windows 7, the path is:
C:\PROGRA~2\MOZILL~1\firefox.exe
(Note the different figure behind PROGRA~ , as I figured out by Abu Sithik's post)
Issue 2: Where to set the path?
You should do the setting (as RiggsFolly had already correctly said) in:
Window > Preferences > General > Web Browser > Firefox > Edit
and NOT (as I did intuitively) in Run > Debug Configurations > Web browser > Firefox - Internal Server.
At least, as far as I tried out (but I'm a relative Eclipse novice) it seems this setting doesn't influence the path that Eclipse/xdebug/java uses to start the browser in an xdebug session.
I hope this helps anyone prevent wasting time as I did fiddling around in vain, when switching between computers running resp. 32 bits and 64 bits Windows, and having to change the path to the firefox executable, until at a certain moment by luck I got the correct ways as indicated above...
I have the same problem, but suddently works when I select de 'Default system web browser instead of Firefox directly. My default web browser is Firefox and now it starts oks.
I hope this helps.
my python27 app deployment is failing for some reasons:
2012-03-09 16:46:25 Running command: "['C:\\Python27\\pythonw.exe', '-u', 'C:\\Program Files (x86)\\Google\\google_appengine\\appcfg.py', '--no_cookies', u'--email=malartre#scolab.com', '--passin', 'update', 'C:\\Users\\XXXXXXXXXXXXXX\\GoogleAppEngine\\XXXXXXXXXXXXXX']"
Application: XXXXXXXXXXXXXX; version: 1
Host: appengine.google.com
Starting update of app: XXXXXXXXXXXXXXX, version: 1
Getting current resource limits.
Password for malartre#scolab.com: Scanning files on local disk.
Scanned 500 files.
Scanned 1000 files.
Scanned 1500 files.
Scanned 2000 files.
Scanned 2500 files.
Cloning 2973 static files.
Cloned 100 files.
Cloned 200 files.
Cloned 300 files.
Cloned 400 files.
Cloned 500 files.
Cloned 600 files.
Cloned 700 files.
Cloned 800 files.
Cloned 900 files.
Cloned 1000 files.
Cloned 1100 files.
Cloned 1200 files.
Cloned 1300 files.
Cloned 1400 files.
Cloned 1500 files.
Cloned 1600 files.
Cloned 1700 files.
Cloned 1800 files.
Cloned 1900 files.
Cloned 2000 files.
Cloned 2100 files.
Cloned 2200 files.
Cloned 2300 files.
Cloned 2400 files.
Cloned 2500 files.
Cloned 2600 files.
Cloned 2700 files.
Cloned 2800 files.
Cloned 2900 files.
Cloning 3 application files.
Uploading 4 files and blobs.
Uploaded 4 files and blobs
Compilation starting.
Compilation completed.
Starting deployment.
Rolling back the update.
Error 400: --- begin server output ---
Client Error (400)
The request is invalid for an unspecified reason.
--- end server output ---
2012-03-09 16:47:14 (Process exited with code 1)
You can close this window now.
How can I debug that?
Thanks,
Carl
Just recording my experience in this related question.
I got a 'Client Error 400/unspecified reason' because my app.yaml error handlers were pointing to files in a static directory.
I moved the error files to a separate directory and updated app.yaml paths.
Update worked properly.
i know this is an old question, but i thought i would provide the solution that worked for me. Select Control from the GAE Launcher, then Clear Deployment Credential. Deploy again. The deployment script will open a web page where GAE is requesting access to use your Google account to authenticate. the answer from Jen Tong helped me get to my solution.
This is a fall-back error message that is triggered when your deployment sends very unexpected data to App Engine during deployment.
In other words, there's no quick fix here, but there are a couple things you can check:
Check your apps metadata in app.yaml for Python and appengine-web.xml for Java. Double check each field. If the application name is very wrong, it may trigger this error.
Make sure that your deployment credentials are valid. If you're authenticating with OAuth 2.0, try using password based authentication.
Deleting some files worked for me. Looks like there may be a 1000 file hard limit for apps on GAE, and this obscure error code is at least in part used to document being over the limit.
http://www.adampresley.com/2011/06/gae-and-client-error-400.html
I has this because I had an rogue ) in my app.yaml. I'd check the last thing(s) you did for errors because although your app may upload, an error may cause the application not to deploy.
One of the causes of this error is having more than 1000 files in a folder.
For me I had about 1k images but then 9 folders and I think that put it over the top. I haven't checked if the limitation also exists for folder counts but I imagine it does.