I am trying to become a Jenkins user through this command - sudo su -s /bin/bash jenkins.
When I do run it, this happens in my shell: bash-4.2$ Killed.
I have been trying to debug it by identifying the memory allocation used on the server (we have plenty), reading debug lines of processes being killed, and the jenkins log but there's nothing that leads me towards a solution.
How do I start to debug this problem and what could be going on? There aren't any obvious errors being thrown my way.
I've discovered that when I restart the server, I can log in as the jenkins user and the jenkins builds work. However, shortly thereafter, I cannot log in and the builds no longer work.
Related
I've recently updated git bash to 2.35.1. I do Minecraft plugin/server development so am often using git bash to start and manage test servers in windows. Unfortunately I do not know what version I was on before.
Now when I started a server using java -Xms4G -Xmx4G -jar server.jar it boots, but I can't type anything into the console. I am completely locked out. Using CTRL+C will shutdown the server but it says "do you want to terminate the batch job" and hangs. I have to force quit the java process.
Before, I could type game console commands in without issue.
I've tried running git bash as administrator, no change. PowerShell doesn't work at all, it won't even show the output of the console after starting the jar.
When I stop the server from in-game, I get this error after it fully stops:
$ stop
bash: stop: command not found
I have Jenkins running on OSX 10.8.2. I will often leave a session logged in and su'd into the Jenkins account.
On occasion I will get a cryptic call/email/text from a socially inept user who say simply that "Jenkins is broken" and attaches a useless log snippet indicating that Jenkins could not talk to a remote host because the keys were invalid. The Jenkins build fails. The first thing I do is a "whoami" on the session I'm logged into.
whoami -> _assetcache
I type "exit"
whoami -> root
sudo su - jenkins
whoami -> jenkins
What causes it to think the user has become _assetcache? Why is it fixed by simply logging back into the account? When I check ownership on the jenkins user files they show _assetserver for the user and group too, but logging out and back in seems to clear the issue every time. Any idea what may be causing the issue?
Thanks
I would still like to know what causes this, but I have a hack that addresses the issue and for whatever reason, as strange as it may seem, it works:
As root I run a cron script once a hour that executes: sudo su - jenkins
I don't consider the problem solved, but at least that's a workaround. Longer term, I'm recommending that we simply move off the OSX platform and onto a AWS platform.
I'm try to setup my CI environment on my MacBook Pro with Jenkins. And my source code was in TFS(team foundation system), my MBP can't added in windows domain, because of some restrictions.
I've downloaded the TEE command line client on my MBP
I've added my TEE path to system path.
I've ran "tf eula" in terminal with both logged in local user and sudo
I've installed TFS plugin with jenkins.
All configuration set with TFS plugin.
After I configured a project with Jenkins job, and start build. Job failed, with error message that reminds me needs to ran "tf eula" accept the EULA first.
But if I ran the command which Jenkins just ran directly in terminal, everything went well, I've successfully connected to TFS server.
I've no idea why this phenomena happened. Would that because jenkins triggered the command with my domain user name? Which my jenkins error log, the first line indicates job was running under my current logged on local user account.
Jenkins usually runs with it's own user. You need to logon as Jenkins user before executing that command
sudo su jenkins
I have a build job on jenkins that is building my project and after it is done, it opens an ssh shell script on a remote server and transfers files and then stop and starts a daemon.
When I stop and start the daemon from the command line on a RHEL server, it executes just fine. When the job executes in jenkins, there are no errors.
The daemon stops fine and it starts fine. But shortly after starting, the daemon dies suddenly.
sudo service daemonName stop
# transfer files.
sudo service daemonName start
I'm sure that the problem isn't pathing
Does anyone know what could be special about the way Jenkins is executing the ssh shell script that would cause the daemon start to not fully complete?
The problem:
When executing a build through jenkins, the command to start the daemon process was clearly successfully executing, yet after the build job was done, the daemon would suddenly quit.
The solution:
I thought for this whole time that it was jenkins killing the daemon. So I tried many different incarnations and permutations of disabling the ProcessTree module that goes through and cleans up zombie child processes. I tried fooling it by resetting the BUILD_ID environment variable. Nothing worked.
Thanks to this thread I found out that that solution only works for child processes executed on the BUILD machine. I.E. not applicable to my problem.
More searching led me here: Run a persistent process via ssh
The solution? Nohup.
So now the build successfully restarts the daemon by executing the following:
sudo nohup service daemonname start
Jenkins watches for processes spawned by the job and kill them to avoid zombie processes.
See https://wiki.jenkins-ci.org/display/JENKINS/ProcessTreeKiller
The workaround is to override the BUILD_ID environment variable:
BUILD_ID=dontKillMe
I have a complex script - that Jenkins executes on build - which needs to check for events in /var/log/syslog. In order to do so, I added the user "jenkins" to the group syslog belongs to and set the file permissions to 0640.
The script above runs perfectly fine when manually executed, but when invoked by Jenkins build system it fails: indeed, the output console shows that the script has not the permission to read /var/log/syslog when invoked via Jenkins.
A quick check with whoami shows that the building process runs with "jenkins" as user, though. Hence, I cannot understand why the script behavior is different.
I haven't used jenkins, so this might not be what's going on, but do you know if you are running under SELinux or any other sort of mandatory-access-control system?
That tends to be my knee-jerk reaction to strange permissions issues.
If SELinux is enabled, try checking /var/log/audit/audit.log to see if there are any denials to read /var/log/syslog.
If you are on Linux, the command "getenforce" should tell you whether SELinux is running or not.