I'm trying to use 2 commands:
xcodebuild archive -workspace MyProject.xcworkspace -scheme Prod -configuration Prod -archivePath "${WORKSPACE}"/build/MyProject.xcarchive
and
xcodebuild -exportArchive -exportProvisioningProfile "Prov Profile" -exportFormat IPA -exportPath "${WORKSPACE}"/build/MyProject.ipa -archivePath "${WORKSPACE}"/build/MyProject.xcarchive
However, there are way too many lines being logged - around 90k lines or so. normally this isn't a problem, but...
i'm running this on Jenkins, so the log is being logged in JVM memory and i'm getting some weird out of memory exceptions during my jenkins runs (which i think is because somehow with 64 builds, it's showing me 90k lines of logs as opposed to previously 50k lines of logs).
Is there a way to make it so that the logs are silent, until something fails? 90k logs is a LOT of lines to be logging for xcodebuild
I have a hack around this:
have the output be piped to a file on the jenkins server, and tail -f that file to get the logs. you can then even email that tail (if the command had succeeded).
that way, you avoid logging into console, instead you log to file.
something like:
xcodebuild archive -workspace MyProject.xcworkspace -scheme Prod -configuration Prod -archivePath "${WORKSPACE}"/build/MyProject.xcarchive > ~/dzt/tmp/archive_results.txt
Related
I am trying to use a tool that, in two steps, analyzes code smells for android.
In the first step, the tool parses an apk and generates within a directory .db files that should then be converted to CSV files in the next step; however, whenever I try to run the second step, the console returns the following error:
java.io.IOException: Unable to create directory path [/User/Desktop/db2/logs] for Neo4j store.
I think it is a Neo4J configuration problem.
I am currently running the tool with the following Java configuration:
echo $JAVA_HOME
/home/User/openlogic-openjdk-11.0.15
update-alternatives --config java
* 0 /usr/lib/jvm/java-11-openjdk-amd64/bin/java 1111 auto mode
To be safe, I also started Neo4J, which returned the following output
sudo systemctl status neo4j.service
neo4j.service - Neo4j Graph Database
Loaded: loaded (/lib/systemd/system/neo4j.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2022-07-06 20:11:04 CEST; 16min ago
Main PID: 1040 (java)
Tasks: 57 (limit: 18901)
Memory: 705.4M
CPU: 16.639s
CGroup: /system.slice/neo4j.service
└─1040 /usr/bin/java -cp "/var/lib/neo4j/plugins:/etc/neo4j:/usr/share/neo4j/lib/*:/var/lib/neo4j/plugins/*" -XX:+UseG1GC -XX:-OmitStackTraceInFastThrow -XX:+AlwaysPreTouch -XX:+UnlockExper>.
How can I solve this?
You posted this error:
java.io.IOException: Unable to create directory path [/User/Desktop/db2/logs] for Neo4j store.
From that error, it looks like:
Neo4j was installed at "/User/Desktop/db2"
The permissions for that directory do not have "write" permission
I tried to reproduce this locally using Neo4j Community 4.4.5, following the steps below.
I do see an IOException related to "logs", but it's slightly different from what you posted. Perhaps we're on different versions of Neo4j.
Open terminal into install directory: cd neo4j
Verify "neo4j" is stopped: ./bin/neo4j stop
Rename existing "logs" directory: mv logs logs.save
Remove write permission for the Neo4j install: chmod u-w .
Start neo4j in console mode: ./bin/neo4j console
Observe errors in console output
2022-07-08 03:28:38.081+0000 INFO Starting...
ERROR StatusLogger Unable to create file [****************************]/neo4j/logs/debug.log
java.io.IOException: Could not create directory [****************************]/neo4j/logs
...
To fix things, try:
Get a terminal into your Neo4j directory:
cd /User/Desktop/db2
Set write permissions for the entire directory tree:
chmod u+w -R .
Start neo4j in console mode:
./bin/neo4j console
If this works and you're able to run neo4j fine, it points to an issue with user permissions when running neo4j as a system service.
The best steps from there depend on the system, your access, how comfortable you are making changes, probably other things. An easy, brute-force hammer would be to manually create each directory you discover (such as "/User/Desktop/db2/logs") and grant premissions to all users (chmod ugo+w .), then try re-running the service, see what errors pop up. Repeat that until you're able to run the service without errors.
My company wants us to save logs from the past 3 months. Catalina.out is getting too large on the linux server (Red hat). How can I remove everything in the log except for the last 3 months in the ONE catalina.out file.
I had a requirement slightly similar to you case. This is how I tackled the requirement.
Add following Linux commands into Cron Scheduler
grep the required date stamp i.e. 2022-05-07 and write to new file
grep "2022-05-07" > 2022_05_07.log // write lines which matches the data stamp
wc -l 2022_05_07.log // outputs how many lines captured
Clear the log of catalina.out file without stopping tomcat with the command below.
sudo cat /dev/null > /opt/tomcat/apache-tomcat-9.0.37/logs/catalina.out
Make note it is not recommended to delete the catalina.out while tomcat is running.
It will keep on logging to catalina.out which is removed already (reference of the file is hold by the tomcat) hence the space will not be released. So you will need to restart the tomcat sever to release the space.
pid - 808 just quit unexpectedly, please check logs under /opt/logs/100003171 and /tmp for more information![enter image description here][1]
lsLinHaiZhao ~/Desktop/apollo/apollo-configservice/target/apollo-configservice-2.0.0-SNAPSHOT-github/scripts (master)
$ sh startup.sh
mkdir: cannot create directory ‘/opt’: Permission denied
Windows new JAVA_HOME is: /c/PROGRA~1/Java/JDK18~1.0_4
2022年02月22日 16:18:17 ==== Starting ====
LOG_FOLDER /opt/logs/100003171/ does not exist. Falling back to /tmp
Started [808]
Waiting for server startup.
pid - 808 just quit unexpectedly, please check logs under /opt/logs/100003171 and /tmp for more information!
lsLinHaiZhao ~/Desktop/apollo/apollo-configservice/target/apollo-configservice-2.0.0-SNAPSHOT-github/scripts (master)
$
1.Database password cannot be used: special characters can be used to modify the database password!
2.If the database is not started, the same error will be reported. Restart the database!
3.Not here Configure the contents of relevant databases in the properties file or YML file, and comment out the unnecessary or redundant configuration information, and restart it!
There are three possible mistakes, each of which can lead to the above mistakes. Carefully examine your own problems. Using these three solutions can solve your problems!!!
Trying to deploy a Play Framework based Application using an ELB container
Recently it seems that AWS made changes to the way ELB works as we've done this before without issue.
The error we currently get is:
2021/12/14 23:00:15.705423 [INFO] Executing instruction: CheckProcfileForJavaApplication
2021/12/14 23:00:15.705468 [ERROR] An error occurred during execution of command [app-deploy] - [CheckProcfileForJavaApplication]. Stop running the command. Error: there is no Procfile and no .jar file at root level of your source bundle
2021/12/14 23:00:15.705474 [INFO] Executing cleanup logic
2021/12/14 23:00:15.705598 [INFO] CommandService Response: {"status":"FAILURE","api_version":"1.0","results":[{"status":"FAILURE","msg":"Engine execution has encountered an error.","returncode":1,"events":[{"msg":"Instance deployment failed. For details, see 'eb-engine.log'.","timestamp":1639522815,"severity":"ERROR"}]}]}
Now of course I wouldn't be here if this was the actual problem
# cd /var/app/staging/server-xxxxxxxxxxx/
# ls -l
total 16
-rw-r--r-- 1 webapp webapp 135 Dec 14 20:39 Procfile
drwxr-xr-x 2 webapp webapp 82 Dec 14 22:21 bin
drwxr-xr-x 2 webapp webapp 113 Dec 14 22:21 conf
drwxr-xr-x 2 webapp webapp 8192 Dec 14 22:21 lib
drwxr-xr-x 3 webapp webapp 17 Dec 14 22:21 share
So Procfile exists
Hmmm is it valid however?
Let's check that out:
# cat Procfile
web: bin/server -v -J-Xms512M -J-Xmx2048m -J-server -Dhttp.port=5000 -Dhttps.port=8443 -Dconfig.resource=application.conf
Looks normal enough -- but does it actually work?
Short answer is yes -- if I copy and paste that command (minus the "web:" prefix of course) system comes up without any issues (ELB still fails to realize that though...)
I've tried a few variants of the command thinking that it might be related to yaml formatting of perhaps a tighter regex ^[A-Za-z0-9_-]+:\s*[^\s].*$ (source: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/platforms-linux-extend.html)
web: bin/server
web: ./bin/server
web: bin/server
web: ./bin/server
web:bin/server
web:./bin/server
No difference (both worked when manually started without or without the leading ./ btw)
Unsure how I move forward here?
How do we find what the real problem is so that we have fighting chance to fix it?
And yes -- the initial trace above is already the output of eb-engine.log
Using (in case this is relevant)
Coretto Java 11
Play 2.8.8
Scala 2.13.6
SBT 1.5.2
Will answer any relevant queries that help improve this question and any chance of resolving it. Most Google searches I've dug through are related to other environments and are simply a missing Procfile...
I have worked out the following work-around to be able to use a standard (well slightly modified) Play Framework dist directly in an AWS ELB Java container
We start with the typical sbt dist process to create a zip "distribution" file
That file won't work in the format it is currently in (I've been researching and I will be asking specific questions to see if making it work directly might be possible) however it only takes a few small tweaks to get it to work
First Step: Modify Procfile (a file that you manually create and place in the project's dist directory) as follows:
web: chmod 700 bin/server; bin/server -v -J-Xms512M -J-Xmx2048m -J-server -Dpidfile.path=/dev/null -Dhttp.port=5000 -Dconfig.resource=application.conf
Note the chmod 700 bin/server; that was the final secret sauce required to make this work! I was kinda shocked that it did work actually. I did not think that would get past the regex they use to parse the Procfile
As a zip file is permissions agnostic, once I finally got the elb install process to get past that first "missing jar" hurdle I noticed the permissions on bin/server were simply rw. The ec2 instance's /var/log/eb-engine.log did not quite spell that out too clearly, however I confirmed that whenever I manually modified those permissions (on the ec2 instance) and then ran the bin/server command (to verify it) the Play server would start right away (however the elb container still failed to see it as a legitimate process and continued to report it as Status of no data, nor did it allow the load balancer to send it traffic so this "fix" was a real shot in the dark!)
Second step: Unzip that zip file and cd into the directory it created/assigned
cd server-vxxxxxxxxxxxxxx
touch placeholder.jar
The second dab of secret sauce is that the placeholder.jar file is simply a means to satisfy the CheckProcfileForJavaApplication which simply looks for the existence of any file named *.jar in the root of the bundled directory. If that file does not exist then the elb install script stops dead in it's tracks.
Note: You could simply place this empty placeholder.jar file in the Play dist folder if you prefer
Third Step: Create a new zip file elb.zip
zip --exclude share/doc/api/\* -r elb.zip .
Now take elb.zip and upload it to an AWS ELB container and low and behold it (finally) springs to life!
I wonder why my spring project with tomcat server got catalina.out file with size 40GB. Any solutions, please.catalina.out reach 40 GB
catalina.out reaches such a large size because:
1- there might be many logging messages sent to console handler, and
2- also there is not any rotation of catalina.out (and no policy to remove older catalina.out).
First, as there might be some duplication and the messages in catalina.out , which could also be stored in *log messages too, I'd check if the contents of the log files (catalina.[DATE].log) are the same as those of catalina.out, if so then you can edit file conf/logging.properties and remove console handler
I'd also check the level of the log messages and set a higher level if possible. Look for this line in conf/logging.properties
java.util.logging.ConsoleHandler.level = ....
Possible levels, in increasing level of frequency are SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST or ALL. I'd try replace ALL, FINEST, FINER, FINE by CONFIG or even INFO. For instance, by setting it to INFO, all SEVERE, WARNING and INFO messages will be logged but not any with a level to the right of that list.
Also another option is set a limit to console handler by adding this line to conf/logging.properties
java.util.logging.ConsoleHandler.limit = 1024000
and rotate catalina.out configuring an automatic task to remove older ones.
if you are linux user to handle this from system is pretty easy you can configure logrotation with logrotate this is very easy
Step : 1 (Create Logrotate file)
root#c2dapp01-usea1e# vim /etc/logrotate.d/tomcat
Step : Add rotation instruction for linux log rotator
/opt/tomcat/latest/logs/catalina.out {
copytruncate
daily
rotate 7
compress
missingok
size 100M
}
Step : 3 Add cron job to run daily in crond.daily or create custom cron (This file is by default there if not then only create)
root#c2dapp01-usea1e:# vim /etc/cron.daily/logrotate
# Clean non existent log file entries from status file
cd /var/lib/logrotate
test -e status || touch status
head -1 status > status.clean
sed 's/"//g' status | while read logfile date
do
[ -e "$logfile" ] && echo "\"$logfile\" $date"
done >> status.clean
mv status.clean status
test -x /usr/sbin/logrotate || exit 0
/usr/sbin/logrotate /etc/logrotate.conf
This script can be run manually.
/usr/sbin/logrotate /etc/logrotate.conf
Most probably the huge size of logs is due to the DEBUG mode setting of log4j. Change this setting to WARN and the size of logging will be reduced.
This is quite common to see catalina.out file expanding.
this could be used to clear the log of catalina.out file without stopping tomcat with the command below.
sudo cat /dev/null > /opt/tomcat/apache-tomcat-9.0.37/logs/catalina.out
To keep catalina.out smaller in size, either one of the following ways can be used:
You could use the above Linux command and add it to a CronScheduler
to run daily/ weekly/ monthly or yearly as preferred.
Use logrotate tool in Linux. It is a log managing command-line tool
in Linux. This can rotate the log files under different conditions.
Particularly, we can rotate log files on a fixed duration or if the
file has grown to a certain size. You can click here for more
info on this.