We Keep Coding

Prevent application (iscsiadm) logging to dmesg?

I have an issue where running sudo iscsiadm -m discovery -t st -p IP -l logs to dmesg across all terminals on the server.
The command is run from a java application, using:
Runtime.getRuntime().exec("/bin/bash", "-c", "sudo iscsiadm -m discovery -t st -p *IP* -l");
I have tried the following:
Apppending > /dev/null 2>&1 to the end of the iscsiadm discovery... command
Capturing input streams from the returned progress (process.getInputStream() and process.getErrorStream())
Appending > /dev/null 2>&1 to the software launching the Jar.
None of the above attempts prevent logging across all virtual terminals. The log starts [some_num.some_dec] LOG_MESSAGE which suggests it is outputting to dmesg? If this is true how do I prevent this? Currently it makes the system impossible to debug because it's printing over the terminal prompt.
Thanks

Issue fixed.
It turns out it was not iscsiadm logging to dmesg, it was the mount command afterwards because the blockdev did not exist.
I have modified my java code to try iscsiadm -m discovery... then run iscsiadm -m session to determine if the appropriate device has a connection or not prior to mounting.

Why after that I quit a Spring Boot application in a Linux shell (by CTRL+Z) a process still listen on the 8080 port? (the port used by my application

I am working on a Spring Boot application running it on a Linux machine.
It is a batch application containing Spring Boot Admin tool listening on the 8080 port.
I have the following "problem": I run it into my shell for the first time using this command:
mvn spring-boot:run
it correctly start and I can access to the Spring Boot Admin tool panel at this address http://localhost:8080/
Supse that I stop my batch application execution clicking CTRL+Z on my keyboard, so the Spring Boot application is now stopped and I obtain this output message:
[1]+ Stopped mvn spring-boot:run
Ok, now if I run again my application by the same start command:
mvn spring-boot:run
now I am obtaining this error message:
Description:
Web server failed to start. Port 8080 was already in use.
Action:
Identify and stop the process that's listening on port 8080 or configure this application to listen on another port.
So if I perform this command to find the process that is listening on port 8080:
andrea#ubuntu:~/git/notartel-api-batch$ netstat -ltnp | grep -w ':8080'
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp6 2 0 :::8080 :::* LISTEN 16269/java
If now that I killed the previous process I restart again my Spring Boot application it will be started without problem.
Why if I quit a Spring Boot application listening on the 8080 port (using CTRL+Z into the Linux shell), this process still listen on this port? I expected that the entire application will be killed and that nothing listen on the port

Ctrl + Z doesn't kill the application but suspend it and put it in background, use Ctrl + C if you want to abort the running application.

I do this command in my terminal to clear the process in port 8080.
kill `lsof -i -n -P | grep TCP | grep 8080 | tr -s " " "\n" | sed -n 2p`
Ctrl+C is used to kill a process with signal SIGINT, in other words it is a polite kill .
Ctrl+Z is used to suspend a process by sending it the signal SIGTSTP, which is like a sleep signal, that can be undone and the process can be resumed again.
However when a process is suspended, we can resume it again by fg (resume in foreground) and bg (resume in background) , but I can't resume a killed process, that is a difference between using Ctrl+C & Ctrl+Z.

If you are running this
mvn spring-boot:run
on some other terminal the process will not stop listening on port if you close your IDE.
Instead of running mvn spring-boot:run you can just run the Main file of the application. After that when you close your application, the port will not listen.

Can't bind to local 8632 for debugger

I am facing the error when launching the app i the emulator for the first time .emulator is from android not third party emulators
port 8632 error

Looks like the port is used by another process.
If you are using Windows, run the following command:
netstat -a -n -o
If you are using Linux, run the following command:
sudo ss -tulpn | grep :8632
And stop/kill the process ID that is using this port.

It looks like your port is occupied
you can run lsof -i:8632 to check what process is run on port 8632 and kill it kill -9 PID
or....restart your computer

Exception in thread "main" java.io.StreamCorruptedException: invalid stream header: 0BDAACED

I am trying to execute jenkins cli command from master.
ssh user#192.168.1.2 -C "/usr/bin/java -jar /home/user/slave.jar"
Getting following error:
<===[JENKINS REMOTING CAPACITY]===>Exception in thread "main" java.io.StreamCorruptedException: invalid stream header: 0BDAACED
at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:808)
at java.io.ObjectInputStream.<init>(ObjectInputStream.java:301)
at hudson.remoting.ObjectInputStreamEx.<init>(ObjectInputStreamEx.java:48)
at hudson.remoting.ChannelBuilder.makeTransport(ChannelBuilder.java:430)
at hudson.remoting.ChannelBuilder.negotiate(ChannelBuilder.java:389)
at hudson.remoting.ChannelBuilder.build(ChannelBuilder.java:310)
at hudson.remoting.Launcher.main(Launcher.java:528)
at hudson.remoting.Launcher.runWithStdinStdout(Launcher.java:468)
at hudson.remoting.Launcher.run(Launcher.java:242)
at hudson.remoting.Launcher.main(Launcher.java:195)
ERROR: Unexpected error in launching an agent. This is probably a bug in Jenkins
hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected EOF
at hudson.remoting.Request.abort(Request.java:303)
at hudson.remoting.Channel.terminate(Channel.java:847)
at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:92)
at ......remote call to ubuntu-slave(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1416)
at hudson.remoting.Request.call(Request.java:172)
at hudson.remoting.Channel.call(Channel.java:780)
at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:508)
at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:381)
at hudson.slaves.CommandLauncher.launch(CommandLauncher.java:131)
at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:253)
at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: Unexpected EOF
at hudson.remoting.ChunkedInputStream.readUntilBreak(ChunkedInputStream.java:99)
at hudson.remoting.ChunkedCommandTransport.readBlock(ChunkedCommandTransport.java:39)
at hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:34)
at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:59)
ERROR: Connection terminated
java.io.IOException: Unexpected EOF
at hudson.remoting.ChunkedInputStream.readUntilBreak(ChunkedInputStream.java:99)
at hudson.remoting.ChunkedCommandTransport.readBlock(ChunkedCommandTransport.java:39)
at hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:34)
at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:59)
ERROR: Process terminated with exit code 1
Please tell me what could be the problem?

The short answer
Jenkins' slave.jar communicates with the Jenkins server through the slave's stdin/stdout. You rely on ssh to transfer stdin/stdout to/from the slave.
Something that you are not aware of tampers with the stdin before it reaches the slave, and the resulting communication protocol violation causes the exception that you see.
The longer explanation and a fix
I suppose that you have the ssh command from your question, which starts the slave, in a shell script on the jenkins server, and that this shell script also has other commands in it that precede this command. Because this is how it was in my case, inspired by the jenkins remoting documetation that suggests you could do things like copying the correct slave.jar to the slave.
So we are both using the "Launch agent via execution of command on the server" option to start the slave agent. In my case I do this to be able to use an ssh jump host to reach the slave, but this is not of relevance to this answer.
I will now give examples of non-working and working shell scripts to start a slave.jar on a remote node, and then come up with reasoning of what might cause the observed behaviour. I use /bin/bash as the shell, feel free to use others.
1) These versions both work if you already have slave.jar on the slave
#!/bin/bash
ssh user#host "java -jar /home/user/slave.jar"
.
#!/bin/bash
exec ssh user#host "java -jar /home/user/slave.jar"
Both versions have only a single command in them. Nothing else is in here that tampers with stdin or stdout. In the first version, the shell lingers around and forwards stdin/stdout to/from the ssh command. In the second version, the shell is replaced by the ssh process and directly inherits its stdin/stdout. Both versions work ok, and the additional shell process in the first version should not matter on any system.
2) This version copies slave.jar from some location on the server to the slave before executing it on the slave
#!/bin/bash
scp -q /some/location/slave.jar user#host:.
exec ssh user#host "java -jar /home/user/slave.jar"
Of course, this only works if you have /some/location/slave.jar on the server.
3) This version tries to do some additional cleanup on the slave before starting the slave agent.
#!/bin/bash
ssh user#host "rm -rf /home/user/tmp/jenkins"
exec ssh user#host "java -jar /home/user/slave.jar"
The /home/user/tmp/jenkins location on the slave is just an example.
This version fails after a 4 minute timeout. With the exact error message from the question. The failure is not caused by anything important missing from /home/user/tmp/jenkins, as you will see in the next example:
4) Different ways to make example 3 work
#!/bin/bash
ssh user#host "rm -rf /home/user/tmp/jenkins" </dev/null
exec ssh user#host "java -jar /home/user/slave.jar"
.
#!/bin/bash
exec ssh user#host "rm -rf /home/user/tmp/jenkins && java -jar /home/user/slave.jar"
In the first fix, we make sure stdin to communicate with the slave is not forwarded to the remote rm command. rm does not read its stdin, but apparently ssh does not know that and buffers some bytes from its own stdin and forwards them to the remote command just in case it is needed? This is fixed by forwarding /dev/null as stdin to the rm command instead of the stdin destined for the slave communication.
In the second fix, only one ssh command is used, the rm command again does not read anything from stdin, and the slave.jar receives the untampered stream.

Tomcat shutdown: The process cannot access the file

people.
Can somebody please help with this...
After Tomcat started by running startup.bat - need to stop it but get:
c:\Opt\tomcat_8080\bin>shutdown.bat
Using CATALINA_BASE: c:\Opt\tomcat_8080
Using CATALINA_HOME: c:\Opt\tomcat_8080
Using CATALINA_TMPDIR: c:\Opt\tomcat_8080\temp
Using JRE_HOME: C:\Opt\jdk1.6.0_32x64\jre
Using CLASSPATH: c:\Opt\tomcat_8080\bin\bootstrap.jar
The process cannot access the file because it is being used by another process.
I can't use taskkill - because there is few java.exe processes - so I can't get PID of just Tomcat... Just kill it manually from Process Explorer - but need to do it automatically, from script which will be called from TeamCity server.
OS - Windows 7, Tomcat 5.5.36.

Solved by:
1) Added line to /bin/startup.bat:
set title="Tomcat"
So now I have description of Java process in tasklist (needed because there is few Java process and need to kill only Tomcat).
2) First command - select process with Title Tomcat and write it in to file:
>tasklist /v /FI "IMAGENAME eq java.exe" | findstr /i "Tomcat" > tomcatpid.txt
3) Second command - select TOKEN 2 (which is PID of previously selected process) and run taskkill:
>for /F "TOKENS=2" %a in ('type tomcatpid.txt') do (taskkill /PID %a)
>(taskkill /PID 3360 )
SUCCESS: Sent termination signal to the process with PID 3360.
Hope - this will help somebody :-)
I sure there more simple solution - but writing scripts for Windows are mnot my favorite occupation...