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.
Related
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.
We have a .CMD script that we are triggering from Control-M.
A main.cmd is being called from Control-M. This script is run as 'accnt_svc' service account which we also configured in Control-M. Prior to setting up in Control-M, we testing this running fine when ran from command prompt (as administrator) and via Windows Task Scheduler being run as the 'acct_svc' service account.
When running in Control M, the log shows error saying a subscript (say sub.cmd is being called from main.cmd) saying the sub.cmd is invalid.
We checked the permissions and they both have the same settings.
We tried another script, this time we created a wrapper which 'calls' the main script. This worked fine.
Please check following wrapper:
SET V_CMDDRV=E:
%V_CMDDRV%
CD %V_CMDDIR%
CALL CALL %V_CMDDIR%\main.cmd
When we create a Main_Wrapper.cmd calling the main.cmd this works fine.
May I know why Control-M behaves this way?
Thanks
When issuing a command via Control-M it will by default run from your run as users home directory. From the output you've attached it looks like main.cmd might need to be run from E: instead of the %HOMEPATH% of the acct_svc service account.
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 can run the following command in terminal to mount an encrypted sparsebundle where the bundle password is stored in the keychain.
hdiutil attach '/Volumes/Backup/Mac1.sparsebundle'
I would like to have that command run on a schedule, so I'm using CronniX to create a cron job with that command. But, when it runs at the scheduled time, nothing happens. When I check the cron daemon mail in terminal, it says the following:
hdiutil: attach failed - Authentication error
I'm assuming that it isn't able to read the password from keychain? I don't know. Hoping somebody can shed some light on things, or point me in the right direction.
Thanks
hdiutil depends on some environment variables. Check this (ENVIRONMENT section). So, probably the environment is different when you run from terminal and from cron. According to error, I think this is due to absence of com_apple_diskimages_insecureHTTP. However the same effect will give adding -insecurehttp to the arguments or specify SSL certificate with -cacert/-capath.
I am new to Hudson with PSEXEC, i am using hudson in my computer, i want to run batch file on remote computer from hudson build.
I used PSEXEC to run batch file on remote computer,when i executed from command promt it working successfully.But same i did from Hudson build its hanging..it's not doing anything.so please give any suggestions is there any other way we can handle this.
I want to do this quikly...urgent
Anyones help is appreciable
thanks in advance.
Could it be that psexec is waiting for a user entry? In this case hudson will hang.
Does Hudson runs with your user credentials? if not lunch a command Prompt with the credentials Hudson is running with and see what happens if you call psexec. If hudson runs on the local system account, you can't start a command prompt with it. Than try to run Hudson with your credentials and see what happens.
BTW, did you check Hudsons log files (just in case that there might be something)?
I had the same problem where PSEXEC simply hung.
The solution i found (after trawling for AGES) was to add the parameter -accepteula to the PSEXEC called. Hudson stopped hanging after that.
Very frustrating.
maybe it is too late, but I thought I will post it for others who have the same problem.
Psexec has problem running from any CI server, doesn't matter what CI server you have, is it Hudson, Teamcity, ...).
Psexec hangs when run from the build server.
It doesn't hang for all commands, but with some commands , psexec will hang.
The problem resides with how psexec will read the output of the remote running command.
The ultimate solution is to use other tools than psexec.
You can check this blog of this solution.
But if you need a simpler solution, and you don't care about the output of the command, I came up with a simple solution that suppress the output of the psexec.
You can write a small c# program that will run the psexec command, suppressing its output.
I blogged about that here
I thought I would respond to this since I was having the same hanging problem with TeamCity and psExec. Since I believe it is actually an issue with Java executing psexec, it should apply in the case of Hudson as well.
While I ran into the accepteula issue was early on, you only need to agree once and it sets a registry setting. As user327759 indicates the -accepteula switch in the script would cover your basis the first time and for ever after.
If this doesn't fix your problem, which it didn't in my case, you need to add the "-i" command switch. ex: psexec -i \ServerName "C:\folder\file.bat"
For context regarding this solution, I have included my backstory:
I was able to execute this PsExec command just fine via a MsBuild task, via a .Net wrapper and via straight command prompt usage, but TeamCity would just hang on the execution. It seems that Java is expecting some response on standard in, when it invokes the psexec exe. On the remote server I would see the psexecsvc process fire up and register in the services console appropriately, but then it would stop. After reading many posts such as this one, and struggling for far longer than I would care to admit, I eventually tried -i option, despite not needing this in any other execution scenario outside of TeamCity. The psexec documentation indicates that -i will "Run the program so that it interacts with the desktop of the specified session on the remote system. If no session is specified the process runs in the console session." It is still unclear to me why this makes all the difference for TeamCity.