in our lab some machines' disk I/O is down so if I submit my job to that machine, I can't get it done.
However, I can submit them to machines A and B.
I tried
qsub -l hostname=A,B
But that don't work, it looks like it only allows one hostname(hostname=A)
Is there a workaround?
Thanks!
Try using a wildcard expression; if you want to use A and B hosts :
qsub -l -h='(A|B)'
Related
If I did : qsub myscript.sh
Then it creates in the script path: myscript.sh.e12 and myscript.sh.o12 files.
But if I do : qsub -o /tmp/my.out myscript.sh
Then there is nothing in /tmp and in the script path only the myscript.sh.e12 file.
The output file is lost during the move. I don't know why.
I also tried with #PBS -o in pbs file but same result.
Thanks for your help.
Torque 2.5.7
RHEL 6.2
short answer: don't write output to /tmp/, write to some space you own, preferably with a unique path.
long answer: /tmp/ is ambiguous. Remember: the whole point of using a distributed resource manager is to run a job over multiple, or at least multiply assignable, compute resources. But each such device will almost certainly have its own /tmp/, and
you have no way of knowing to which one your job was written
you may have no rights on the arbitrary_device:/tmp/ on which one your job was written
So don't write output to /tmp/.
I just upgraded to gcutil 1.10.0 and I notice that the table that's returned upon completion of addinstance no longer contains the IP address of the instance. I extract that address to use in other scripts so I noticed it was gone immediately.
Looking at gcutil commands, it looks like "listaddresses" should give me the information I'm looking for; however, it returns no entries, just a table header. (The instance is running when I try this.)
So I guess if we're not going to produce the IP address in the output of addinstance anymore, I could use help figuring out how to get the address by a command-line query.
John K.
You can get the address for the instance by using:
gcutil listinstances --columns=all
Alternatively, you can just specify the columns you want. You can get the list of valid columns using:
gcutil help listinstances
A future release will add this back by default. We removed columns to make it fit on a more typical terminal but perhaps went too far.
In the meantime, you can run:
gcutil listinstances --columns=name,zone,external-ip,status
Sorry for the inconvenience!
Is there any way to create new Hudson job by one more Hudson job based one previous Jobs?
For example if I need to create new bunch of jobs one by one, Automatically create 4 jobs with similar configuration with different parameter
Basically steps like this
create SVN branch I can call svn cp command and make it parametrized using script
Create some build based on new svnbranch name
Later tag it
Or other word, I need to clone the previous job and give the new branch name where ever $ Branch comes in new job.
Thanks
You can try the Hudson Remote API for this kind of task (setting up an Hudson project).
See this tutorial for instance, and remember you can display the help quite easily:
java -jar hudson-cli.jar -s http://your_Hudson_server/ help
So, to copy a job:
java -jar hudson-cli.jar -s http://your_Hudson_server/ copy-job myjob copy-myjob
You could use groovy system script like this :
def jenkins = hudson.model.Hudson.instance
def template = jenkins.getItem("MyTemplate")
def job = jenkins.copy(template,"MyNewJob")
job.scm = new hudson.scm.SubversionSCM("http://base/branches/mybranche")
job.save()
Kind of already covered in the other answers, but for an easy way to copy the config.xml over:
curl --user USER:PASS -H "Content-Type: text/xml" -s
--data-binary "#config.xml" "http://hudsonserver:8080/createItem?name=newjobname"
There seems to be a plugin for jenkins.
https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin
I have not tested the plug-in yet. But if the plugin works, it should alleviate some of human errors from straight copying a job and modifying variables/values.
def jenkins = hudson.model.Hudson.instance
def template = jenkins.getItem("MyTemplate")
def job = jenkins.copy(template,"MyNewJob")
job.save()
I used this now I have to change the parameter values of MyNewJob using Groovy how will I do that?
ex I have a parameter called "Build_BranchName" and the default is //perforce/mybranch
I have to change it to
//perforce/mynewbranch
You have the option that VonC just gave you (which is probably the safest way but you can also go a different rout by just creating a new directory in {Hudson_Home}\jobs (the directory name will be the job name) and copy a modified config.xml in there. The modification will basically just be the SVN URL. You should check out the xml from the job that you are copying. You need to find out how you change the xml file via script, but this is a secondary problem.
Unfortunately, you have to either restart Hudson, or force a reload of the configuration. (visit the page http://:/reload to reload the config).
In case you're willing to use GIT (like I do, mirroring the main SVN repo, onto the Hudson/Jenkins server, and it works great)....
..you could try Stephen Haberman's post-receive-hudson:
This hook creates new jobs for each
branch in the Hudson continuous
integration tool. Besides creating the
job if needed, the user who pushed is
added to the job's email list if they
were not already there.
In any case, that script can give you new hints on how to remote control Jenkins(Hudson).
I have a text based menu running on a remote Linux host. I am using expect to ssh into this host and would like to figure out how to interact with the menus. Interaction involves arrowing up, down and using the enter and back arrow keys. For example,
Disconnect
Data Collection >
Utilities >
Save Changes
When you enter the system Disconnect is highlighted. So simply pressing enter twice you can disconnect from the system. Second enter confirms the disconnect.
The following code will ssh into my system and bring up the menu. If I remove the expect eof and try to send "\r" thinking that this would select the Disconnect menu option I get the following error: "write() failed to write anything - will sleep(1) and retry..."
#!/usr/bin/expect
set env(TERM) vt100
set password abc123
set ipaddr 162.116.11.100
set timeout -1
match_max -d 100000
spawn ssh root#$ipaddr
exp_internal 1
expect "*password:*"
send -- "$password\r"
expect "Last login: *\r"
expect eof
I have looked at the virterm and term_expect examples but cannot figure out how to tweak them to work for me. If someone can point me in the right direction I would greatly appreciate it. What I need to know is can I interact with a text based menu system and what is the correct method for doing this, examples if any exist would be great.
thanks,
-reagan
Try using the autoexpect tool to record an interactive session, and see what the codes look like.
To simplify your life, you might want to setup public key encryption so that you can ssh to the remote host without using a password. Then you can concentrate on testing your software instead of ssh. Google "ssh login without password" for more information. The instructions you will find are straight forward, so don't be afraid.
Have you tried \n\n\r?
mercurial-server manages user database under keys folder. Users and groups are represented by files and folders.
AclExtension relies on linux user group through ssh.
they don't seem to match. or did I miss something?
I have managed to make mercurial-server work. but just don't see how to integrate AclExtension with it so I may have finer grained access control.
Unfortunately, the AclExtension does key its access off of usernames. If you are creating separate UNIX user accounts for each using with hg-ssh you've got everything you need, but if all of your ssh users are using the same Unix user account then the AclExtension isn't going to work for you.
Unless...
I did just look into the acl.py file and it looks like it uses the getpass.py module's getuser which checks the environment for the user name using this code:
for name in ('LOGNAME', 'USER', 'LNAME', 'USERNAME'):
user = os.environ.get(name)
if user:
return user
so it might be possible to fake that out by setting an environment variable in the hg-ssh user's authorized_keys file like this:
command="hg-ssh path/to/repo" environment="LOGNAME=fakeusername" ssh-dss ...
where then you could put fakeusername in ACL rules, and could have a different fakeusername for each key, all running under the same UNIX account.
BTW: Everyone seems to just use hg-ssh alone, I never see the (non-official) mercurial-server app used anymore.
The environment trick doesn't seem to work on my Solaris box; my solution was to pass in the fakeusername as a parameter to hg-ssh and have that set os.environ['LOGNAME'] so that getpass sees it.
command="hg-ssh fakeusername" ssh-dss ...