I'm new to Mesos. I would like to know how do I know whether Mesos master is set up correctly in the node?
I have follow the set up given by http://mesos.apache.org/gettingstarted/
I am unable to run the following command:
Comment: Start mesos master (Ensure work directory exists and has proper permissions).
$ ./bin/mesos-master.sh --ip=127.0.0.1 --work_dir=/var/lib/mesos
but it shown error given:
./bin/mesos-master.sh: line 24: /home/user/mesos-0.20.0/build/src/mesos-master: No such file or directory
What ways should I proceed?
First, a few questions to help us debug your build:
Did the mesos build (make) complete successfully, and did make check pass all the tests?
If /home/user/mesos-0.20.0/build/src/mesos-master does exist, do you have execute permissions on it?
Are you running ./bin/mesos-master.sh from within /home/user/mesos-0.20.0/build/, or did you move the directory elsewhere?
If this is your first attempt at Mesos and you just want to run it and try it out (rather than fix bugs and develop features for it). I would recommend using a pre-built or cloud-deployed version of Mesos, rather than trying to build it yourself. See:
http://mesosphere.com/downloads/
http://mesosphere.com/downloads/details/index.html#apache-mesos
I'd suggest to follow Mesos Getting Started documentation.
After your system requirements are satisfied, following the section:
System Requirements
Once you reach the following section:
Building Mesos
when you execute the make without disabling verbosity, ensure that all process completed successfully. If it stops (e.g. tipically for proxy related issues) try to fix it accordingly or otherwise post your stack somewhere and I would be happy to help (if I can).
Unfortunately, running make check could not reveal the problem sometimes.
Have you run the make check command ? It is said in the documentation that the binaries will only be available after running the make checkcommand.Ì faced the same issue and it was because i didn't run that command.
Related
I am using the Jenkins Azure VM Agents Plugin with a Linux Master, to launch jobs on Windows agents.
I have been through all the configuration steps and everything works fine until I try to use Docker on the agents.
My pipeline script:
pipeline {
agent {
docker {
image 'myurl.io/myimage:latest'
registryUrl 'https://myurl.io/'
registryCredentialsId '123456789abcdefg'
}
}
The pipeline appears to fails on when it runs this command:
docker pull myurl.io/myimage:latest
The error reported comes down to this:
Caused: java.io.IOException: Cannot run program "nohup" (in directory "C:\Jenkins\workspace\Test Pipeline Docker"): CreateProcess error=2, The system cannot find the file specified
Some notes:
I have ticked the box to install git on the image:
The Git tools appear to be successfully installed on the agent VM
This question seems to be related but is it not exactly the same
I am not running the sh command directly, it is being run by the plugin.
I do not think I have access to set the PATH at this stage
This issue on JIRA https://issues.jenkins-ci.org/browse/JENKINS-36776 is related, but it does not seems to be fixed and the suggested workarounds don't seem to apply to my situation
My question
Is there a way to get my pipeline script to work? Maybe there are some extra commands I can somehow execute on the agent after it launches - but before the docker pull command - to add the required directories to the PATH?
Or is there some other workaround?
I think you were on the right track with the question you already found:
Jenkins pipeline sh fail with "cannot run program nohup" on windows
But, according to the wiki page of the docker-pipeline plugin, running docker on windows workers is not supported (a bit hidden though...):
For Jenkins environments which have macOS, Windows, or other agents, which are unable to run the Docker daemon, this default setting may be problematic. [https://www.jenkins.io/doc/book/pipeline/docker/#specifying-a-docker-label]
As far as I can see, there were several tries to add that feature, but it doesn't seem to be added (yet): https://github.com/jenkinsci/docker-workflow-plugin/pull/148
In the last link it is also stated, that fixing the sh/nohup issue will not be your only problem, for example the docker plugin will try to run id to get the user.
Nevertheless, you could try to make linux commands available by editing the path in your pipeline declaration:
https://stackoverflow.com/a/45101214/12338776
EDIT:
Just saw this question is 3 years old... Well. But since there was no answer so far, and a lot of people still seem to get here, it might still help someone.
I am trying to set up a canvas lms on an amazon ec2 Ubuntu environment. I've gone so far until the file generation step of the production environment guide. I've been able to successfully follow the steps until this point.
Steps to reproduce:
I was successful in making the asset directories and taking their ownership as directed in this step:
sysadmin#appserver:~$ cd /var/canvas
sysadmin#appserver:/var/canvas$ mkdir -p log tmp/pids public/assets public/stylesheets/compiled
sysadmin#appserver:/var/canvas$ touch Gemfile.lock
sysadmin#appserver:/var/canvas$ sudo chown -R canvasuser config/environment.rb log tmp public/assets \ public/stylesheets/compiled Gemfile.lock config.ru`
After this, I run 'npm install'
It is at this point that after getting some deprecated warnings I get stuck at this line:
canvas-lms#0.0.0 preinstall /home/ubuntu/canvas/script/gem_npm install
running npm install for gems/canvas_i18nliner/package.json
running npm install for gems/selinimum/package.json
Killed [ ..] / extract:lodash: sill gunzTarPerm modified mode [ 'fp/getOr.js', 420, 436 ]'
What I've already tried:
First I thought it was an error with the port 9418/tcp not being open. I opened this port through amazon ec2 security group inbound rules. This did not work. Then I tried opening all the ports 1-65000 to fix this. It still did not work.
Additional notes:
From the looks of it, it does not looks like a port issue because the script is able to fetch data in the previous steps. Also from the progress bar it can be seen that the extract is failing only when the last 2 dots are left as the progress bar is shows like this: [ ..]. I'm guessing this is a .js creation erorr.
The documentation provides a link to fix those issues but the description of the steps to follow are not very elaborate there as I can't understand what exactly i need to do. Can someone please look into this and help me? Any help is much appreciated.
The File Generation section in the production guide says to follow this link to fix .js creation issues. The solution I found in this link was to add the following code to the compile_template function found in lib/handlebars/handlebars.rb file. The directory lib/handlebars does not exist in /lib
def compile_template(source, id, plugin=nil)
require 'execjs'
require 'multi_json'
P.S. I downloaded my installation directly from the git repository so no chance of this being missing for some reason :/
So kind of a noob here but I can't seem to find any examples or help anywhere. I have a working instance of NSQ, can register tasks, consumers, etc. Unfortunately I did not originally set the system up. What I am trying to do is figure out how to activate some of the built in command line tools that NSQ offers ( nsq_to_file, nsq_tail, etc. ). I found documentation on how to fire them but have no idea where to fire them from.
When I try nsq_tail --channel=MyTestChannel --topic=test --lookupd-http-address=127.0.0.1:4161 i get nsq_tail command not found. The only other thing I know is that NSQ is managed by docker in our circumstance. Any help / a shove in the right direction would be awesome. Thanks!
Did some digging and answered my own question. Hopefully this helps someone since the docs dont really exist:
Make sure NSQ is running by checking out the dashboard: localhost:4171
Install the NSQ library (different than nsq-go) go get github.com/bitly/nsq
Install godep, how bitly manages dependencies go get github.com/tools/godep
Go to bitly src directory cd $GOPATH/src/github.com/bitly
Use docker to compile and test the nsq command line tools sudo docker build nsq
You should see about 5 or 6 steps run followed by a schlew of tests and a success message.
Run nsq_tail you should see something along the lines of --topic is required
Clap your hands, you just installed the command line tools for NSQ.
Might also need to install docker if you don't have it, not referenced above but FYI.
I have installed incron from the EPEL repository (before you ask; YES, I also tried downloading the source and compiling locally; same results) and am attempting to set up a process on my CentOS 6.4 (final) virtual box that I have successfully prototyped on my local Ubunto 12.04 machine:
Some information up front:
SELinux is set PERMISSIVE
I have added my script(s) and called executables to all with NOPASSWD using visudo to get around some permissions issues...
If I invoke my script from the command line with sudo /path/to/my/script.sh arguments it works like a charm.
sudo service incrond status verifies that incrond is running. root and myusername are added to /etc/incron.allow, /etc/incron.deny is empty.
My incrotab for root is:
/path/to/dropfolder/ IN_CLOSE_WRITE sudo /path/to/my/script.sh $#/$#
Events in /path/to/dropfolder/ result in exactly NOTHING happening. No logs are generated, no messages, no actions occur on the files in the folder.
So I have researched: it was suggested that cron runs in a minimal environment and that to execute complex commands/scripts you may have to execute your .bashrc and/or export your PATH at the beginning of the cron command.
Note: I can find no documentation supporting that incron also runs in a minimal environment, but as my google-fu (and bing-fu!) failed to result in any helpful results related directly to incron I figured WTH, I'll try that!
Edit: Documentation indicates that incron run from system tables or root takes env from its host enviroment, therefore only incron executed by non-root users should require any sort of env or PATH fiddling
So… incrontab for root:
/path/to/dropfolder IN_CLOSE_WRITE . /home/myusername/.bashrc; export PATH=$PATH:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin; sudo /path/to/my/script.sh $#/$#"
No dice… tried && instead of ; = no dice. If you can think of a variation on the above I've probably tried it…
So, lets try a little restorecond -R /usr/sbin/incrond /etc/incron* action!
Huh, no change there either.
service incrond stop followed by service incrond start and then service incrond restart … nope, nope, and nope.
Drastic measures: yum remove incron and yum install incron, chkconfig incrond on and then for good measure a sudo reboot!
Nothing.
I don't even get anything from /tmp/ IN_ALL_EVENTS echo boo>>/home/myusername/boofile.txt, hence my inability to even do an env>>envfile.txt to check whether incron is running in a sparse environment… (see above note)
And yet: service incrond status yields incrond (pid xxxx) is running...
What am I missing? It has to be big and obvious and I hope someone can make me feel like an idiot in short order!
further examination of /var/log/cron yields results like this: Aug 14 15:05:30 hostname incrond[1584]: (root) CMD (sudo /path/to/DropFolder/script/subfolder/script-Beta-1.sh /home/username/DropFolder/testfile.file) -yes I made sure my script was executable..
so incrond is indeed attempting to do SOMETHING, but I get no output anywhere... even a simple echo > /dev/pts/0 produces nada results.
thanks for fixing my crap formatting job
Ok, here's the answer:
Despite all documentation I can find declaring it to be the contrary, incrond under CentOS 6.4 runs in a sparse environment and behaves as cron. this is NOT the case under Ubuntu, where incron inherits its environment from root for system tables and root tables and only user tables run in a sparse environment. This of course means that if you're calling a script (I am) the script needs to build it's environment and every thing must have a full path. EVERYTHING. (well, except for shell builtins :p)
numerous Google and and Bing and Stack Overflow and Server Fault searches all told me that cron operates this way, but they all also seemed to indicate that incron operates as described in the documentation, which it DOES under Ubuntu...
Bottom line, it works now, yay!
I guess this just goes to show: when in doubt define the environment and use full paths... er, actually, just do that all time and save yourself a headache.
(this does not address my problem with applying a SELinux security policy for incron, but I'll worry about that later, in another post...)
I have 3 servers for PROD, with the same deployment build configuration, I choose which server to deploy depending on a build parameter.
The issue is that reviewing the history you can't check which environment are you deploying.
I wonder if it's possible one of this solutions:
- Show parameters in the history of a build
- Autotag a build with parameters
I hope I had explained well enough.
Thanks in advance
You can accomplish this with a Command Line build step that echoes the relevant parameters to the build log. For a Windows-based agent, you could do something like:
Run: Executable with parameters
Command Executable: echo
Command Parameters: Deployed to server %your.server.host%
This would simply add a line to the build log that reads, Deployed to server FOO
Autotagging would be pretty cool, but I don't know of a way to do that.