I am trying to run the example on "http://gearman.org/getting_started" on Ubuntu in VirtualBox environment.
At first I tried to download an old version 0.16 by using apt-get install gearman-job-server, apt-get install gearman-tools and everything worked well. The server ran in the background, I was able to create 2 workers and verify that I can call them by creating a client.
I decided to download and compile the latest version, 1.1.6. Now, I am trying to do the same thing with the new version and I am having errors.
I run the server as admin:
sudo gearmand
The statement
gearadmin --getpid
seems to work - it returns me the process ID of the server. Thus, the server is running, and this answer is not relevant.
Now, I am adding a worker:
gearman -w -f wc -- wc -l
It seems to run.
Nevertheless,
gearadmin --workers
results in something that probably represents and empty list :
33 127.0.0.1 - :
.
(In version 0.16, I was able to see 2 lines, the second showing the registered function name.)
Attempting to run the client
gearman -f wc < /etc/passwd
results in
gearman: gearman_client_run_tasks : flush(GEARMAN_COULD_NOT_CONNECT) localhost:0 -> libgearman/connection.cc:671"
This might be the very same problem described in here - the port not specified, but I have no idea how to do it through the command line tool.
Any idea?
Ok, It looks like the answer in here was the key to success. Probably, the "getting started" section was not updated for a while. Indeed, one must specify a port explicitly for gearmand and gearman .
Server:
sudo gearmand -p 5000
Worker:
gearman -p 5000 -w -f wc -- wc -l
Client:
gearman -p 5000 -f wc < /etc/passwd
Related
i'm trying to install Docker-compose on my Raspberry Pi 3+ which installed Raspbian buster.
I followed instruction on docker.com. After I entered command : sudo curl -L https://github.com/docker/compose/releases/download/1.20.0/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose.
It show a table for downloading
Result
It seems nothing downloaded, just have a file docker-compose saved in /usr/local/bin/docker-compose. When I opened it, it empty. Then I enter command docker-compose -v, it displayed error /usr/local/bin/docker-compose : line 1: Not: command not found.
Anyone have solution?
UPDATE:
Added the following command to my answer to download the LATEST version without specifying any version number at all so the download can be scripted.
curl -L "https://github.com/docker/compose/releases/download/$(curl https://github.com/docker/compose/releases | grep -m1 '<a href="/docker/compose/releases/download/' | grep -o 'v[0-9:].[0-9].[0-9]')/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
It's a bit untidy, but it works. If you have a more elegant way than mine, ping it to me in the comments and I'll update my answer.
Just need to set the perms on the file:
chmod +x /usr/local/bin/docker-compose
Use the file command to validate that you pulled the correct arch for your system.
Intro:
Although docker-compose can be installed from a repo per the accepted answer, apt-cache show docker-compose reveals that as of 20211201 the repo version is only v1.25; about 2 years behind the current v2.1.1 release. In order to take advantage of more modern docker file versions, I needed to get the Github download working.
Short Answer:
The Docker documentation for Docker-Compose is WRONG. They forgot to preface the version number in the command with a "v"; consequently the download fails. Apparently this has been wrong for ages...
Longer Answer:
I ran the below command from the Docker-Compose documentation, and substituted the version "2.1.1" for "1.29.1" per Docker's guidance:
To install a different version of Compose, substitute 1.29.2 with the
version of Compose you want to use.
sudo curl -L "https://github.com/docker/compose/releases/download/2.1.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
The resulting download was 9 KB for a 23 MB binary. Clearly the link was bogus. So I went to the root of the address used in the command "https://github.com/docker/compose/releases" and right-clicked on the version of Docker-Compose that I wanted and chose "Copy Link Address"
This revealed the link Docker was telling folks to use didn't have a "v" prefaced before the version number in the https:// address part of the command.
Solution:
Preface a "v" before the version number you want in the link as below and the command executes successfully:
sudo curl -L "https://github.com/docker/compose/releases/download/v2.1.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
BTW, I too was downloading docker-compose for a Raspberry Pi using the aarch64 binary for Ubuntu 20.04 LTS. However, the missing "v" fix for the broken download address should work for any platform.
This is because on a raspberry pi the url part of the command results in
https://github.com/docker/compose/releases/download/1.24.1/docker-compose-Linux-armv7l
Looking at the latest stable release at https://github.com/docker/compose/releases/tag/1.24.1 you can see there is no download for the armv7l architecture so the file is empty because there is nothing to download.
Will update answer once I figured out how to install docker-compose on Raspian.
Edit:
Via apt-get. Note: Currently (Nov. 8 2019) this installs version 1.21 which is not the latest available.
sudo apt-get install docker-compose
Via pip3. (Installs latest)
sudo apt-get install python3-pip
sudo pip3 install docker-compose
And then restart your system with
sudo shutdown -r
I'm experiencing unexpected behavior using acbuild run. To get used to rkt the idea was to start with a CentOS7 based container running a SSH host. The bare CentOS 7 container referenced below as centos7.aci was created on a up-to-date CentOS7 install using the instructions given here.
The script used to build the SSHd ACI is
#! /bin/bash
acbuild begin ./centos7.aci
acbuild run -- yum install -y openssh-server
acbuild run -- mkdir /var/run/sshd
acbuild run -- sed -i 's/PermitRootLogin prohibit-password/PermitRootLogin yes/' /etc/ssh/sshd_config
acbuild run -- sed 's#session\s*required\s*pam_loginuid.so#session optional pam_loginuid.so#g' -i /etc/pam.d/sshd
acbuild run -- ssh-keygen -A -C "" -N "" -q
acbuild run -- echo 'root:screencast' | chpasswd
acbuild set-name centos7-sshd
acbuild set-exec -- /usr/sbin/sshd -D
acbuild port add ssh tcp 22
acbuild write --overwrite centos7-sshd.aci
acbuild end
When it's spinned up using rkt run --insecure-options=image ./centos7-sshd.aci
the server runs but connection attempts fail because the password is not accepted. If I use rkt enter to get into the running container and re-run echo 'root:screencast' | chpasswd inside, I can login. So that acbuild run instruction has just not worked for some reason... To test a bit more, I replaced it by
acbuild run -- mkdir ~/.ssh
acbuild run -- echo "<rkt host SSH public key>“ >> ~/.ssh/authorized_keys
to enable key based instead of password login. It doesn't work: the key is refused. The reason is obvious once you look into the container: there's no authorized_keys file in ~/.ssh/. If I add a
acbuild run -- touch ~/.ssh/authorized_keys instruction before the key appending attempt, the file is created but it's still empty. So again a acbuild run instruction didn't work - without error notice. May it be related to the fact that both „ignored“ instructions use operators like >> and | ? All commands shown in the examples I've seen don't use any such operators yet the docs don't mention anything and a Google search doesn't help either. In dockerfile RUN instructions they also work fine... what is going wrong here?
P.S.: I tried to use the chroot instead of the default systemd-nspawn engine in the „ignored“ acbuild run instructions => same results
P.P.S.: there's no acbuild tag yet on StackOverflow so I had to tag this as rkt - could somebody with enough reputation create one please? Thx
Ok, I understood what happens using the the acbuild run --debug option.
When
acbuild run -- echo 'root:screencast' | chpasswd
gets executed it returns Running: [echo root:screencast] , the pipe is executed on the host machine. To get the intended result it should be
acbuild run -- /bin/sh -c "echo 'root:screencast' | chpasswd"
or in generic form
acbuild run -- /bin/sh -c "<cmd with pipes>"
as explained here
I am on Linux Centos OS. I understand that using "rpm -qa" gives a lot of install paths for the corresponding package. However, I need just the base package install location for the package. Is there any way/command/option in Linux to retrieve the same? My code snippet is to retrieve list of running services and the corresponding package installed is as below:-
for i in $(service --status-all | grep -v "not running" | grep -E running\|stopped | awk '{print $1}');
do
packagename=$(rpm -qf /etc/init.d/$i)
servicestatus=$(service --status-all | grep $i | awk '{print $NF}' | sed 's/...//g' | sed 's/.//g');
echo $tdydate, $(ip route get 8.8.8.8 | awk 'NR==1 {print $NF}'), $i, $packagename, $servicestatus > "$HOME/MyLog/running_services.csv"
done
Now, I need to also get the corresponding package install location as well which is hosting the running service. Is there a way to retrieve this as well along with getting the package names. Please confirm.
Thanks in advance for extending help.
Regards.
Okay, with your answer to my question in the comments, which is much clearer to me than you initial question...
Hi, basically what i need is:- I get a list of all installed services on my Centos using service --status-all. Now, for each service, I need to know the corresponding application package location on linux.
...I'll propose this (tested here on CentOS 6.6):
#!/bin/bash
for i in `chkconfig --list | awk '{ print $1}'`; do
service $i status >/dev/null 2>&1
if [ $?==0 ]; then
rpm -qf /etc/init.d/$i
fi
done | sort | uniq
That spits out all rpm names of the services which are currently running.
A bit more detail as to why your current approach is not going to work:
service --status-all is not going to return information which can be parsed reliably. For example, the output on a VM here:
acpid (pid 872) is running...
auditd (pid 789) is running...
Stopped
cgred is stopped
Checking for service cloud-init:Checking for service cloud-init:Checking for service cloud-init:Checking for service cloud-init:crond (pid 1088) is running...
ip6tables: Firewall is not running.
iptables: Firewall is not running.
Kdump is not operational
mdmonitor is stopped
netconsole module not loaded
Configured devices:
lo eth0
Currently active devices:
lo eth0
ntpd (pid 997) is running...
master (pid 1076) is running...
rdisc is stopped
restorecond is stopped
rsyslogd (pid 809) is running...
sandbox is stopped
saslauthd is stopped
openssh-daemon (pid 988) is running...
Some services don't even return their name (third line). Some say stopped, others not running. If you parse the first column of chkconfig --list you know all the service names, which correspond to files in /etc/init.d. Then you can query their status individually and read the return code ($?), which is 0 for running services (or generally for success in the Unix/Linux world), 1 or higher for not running or not installed or incomplete/malfunctioning services.
Armed with names in /etc/init.d/ you can then query the owning package with rpm -qf /etc/init.d/<servicename> and get exactly what I think you were looking for.
Edit: added | sort | uniq after the loop, because some packages contain multiple services, like for example cloud-init, which creates four different services on CentOS. So you sort the list, then make sure you only get distinct (uniq) names back.
Works for me:
acpid-1.0.10-2.1.el6.x86_64
audit-2.3.7-5.el6.x86_64
cloud-init-0.7.5-10.el6.centos.2.x86_64
cronie-1.4.4-12.el6.x86_64
cyrus-sasl-2.1.23-15.el6_6.1.x86_64
initscripts-9.03.46-1.el6.centos.1.x86_64
iptables-1.4.7-14.el6.x86_64
iptables-ipv6-1.4.7-14.el6.x86_64
iputils-20071127-17.el6_4.2.x86_64
kexec-tools-2.0.0-280.el6.x86_64
libcgroup-0.40.rc1-15.el6_6.x86_64
mdadm-3.3-6.el6.x86_64
ntp-4.2.6p5-1.el6.centos.x86_64
ntpdate-4.2.6p5-1.el6.centos.x86_64
openssh-server-5.3p1-104.el6_6.1.x86_64
policycoreutils-2.0.83-19.47.el6_6.1.x86_64
postfix-2.6.6-6.el6_5.x86_64
rsyslog-5.8.10-9.el6_6.x86_64
udev-147-2.57.el6.x86_64
You are looking for --whatprovides instead of -qf (which does formatting).
Tweaking your example...
for i in $(chkconfig --list | awk '{ print $1}'); do service $i status >/dev/null 2>&1; if [ 0==$? ]; then echo -n "$i: "; rpm -q --whatprovides /etc/init.d/$i; fi; done | sort
FYI - this doesn't work on more modern systemd-based systems (CentOS 7).
Example on my Fedora 21 box:
Note: This output shows SysV services only and does not include native
systemd services. SysV configuration data might be overridden by native
systemd configuration.
If you want to list systemd services use 'systemctl list-unit-files'.
To see services enabled on particular target use
'systemctl list-dependencies [target]'.
netconsole: initscripts-9.56.1-5.fc21.x86_64
network: initscripts-9.56.1-5.fc21.x86_64
I'm trying to create a service / script to automatically start and controll my nodejs server, but it doesnt seem to work at all.
First of all, I used this source as main reference http://kvz.io/blog/2009/12/15/run-nodejs-as-a-service-on-ubuntu-karmic/
After testing around, I minimzed the content of the actual file to avoid any kind of error, resulting in this (the bare minimum, but it doesnt work)
description "server"
author "blah"
start on started mountall
stop on shutdown
respawn
respawn limit 99 5
script
export HOME="/var/www"
exec nodejs /var/www/server/server.js >> /var/log/node.log 2>&1
end script
The file is saved in /etc/init/server.conf
when trying to start the script (as root, or normal user), I get:
root#iof304:/etc/init# start server
start: Job failed to start
Then, I tried to check my syntax with init-checkconf, resulting in:
$ init-checkconf /etc/init/server.conf
File /etc/init/server.conf: syntax ok
I tried different other things, like initctl reload-configuration with no result.
What can I do? How can I get this to work? It can't be that hard, right?
This is what our typical startup script looks like. As you can see we're running our node processes as user nodejs. We're also using the pre-start script to make sure all of the log file directories and .tmp directories are created with the right permissions.
#!upstart
description "grabagadget node.js server"
author "Jeffrey Van Alstine"
start on started mysql
stop on shutdown
respawn
script
export HOME="/home/nodejs"
exec start-stop-daemon --start --chuid nodejs --make-pidfile --pidfile /var/run/nodejs/grabagadget.pid --startas /usr/bin/node -- /var/nodejs/grabagadget/app.js --environment production >> /var/log/nodejs/grabagadget.log 2>&1
end script
pre-start script
mkdir -p /var/log/nodejs
chown nodejs:root /var/log/nodejs
mkdir -p /var/run/nodejs
mkdir -p /var/nodejs/grabagadget/.tmp
# Git likes to reset permissions on this file, but it really needs to be writable on server start
chown nodejs:root /var/nodejs/grabagadget/views/layout.ejs
chown -R nodejs:root /var/nodejs/grabagadget/.tmp
# Date format same as (new Date()).toISOString() for consistency
sudo -u nodejs echo "[`date -u +%Y-%m-%dT%T.%3NZ`] (sys) Starting" >> /var/log/nodejs/grabagadget.log
end script
pre-stop script
rm /var/run/nodejs/grabagadget.pid
sudo -u nodejs echo "[`date -u +%Y-%m-%dT%T.%3NZ`] (sys) Stopping" >> /var/log/nodejs/grabgadget.log
end script
As of Ubuntu 15, upstart is no longer being used, see systemd.
I'm using Fabric to initialize a postgres server. I have to add a "sleep 1" at the end of the command or the postgres server processes die without explanation or an entry in the log:
sudo('%(pgbin)s/pg_ctl -D %(pgdata)s -l /tmp/pg.log restart && sleep 1' % env, user='postgres')
That is, I see this output on the terminal:
[dbserv] Executing task 'setup_postgres'
[dbserv] run: /bin/bash -l -c "sudo -u postgres /usr/lib/postgresql/9.1/bin/pg_ctl -D /data/pg -l /tmp/pg.log restart && sleep 1"
[dbserv] out: waiting for server to shut down.... done
[dbserv] out: server stopped
[dbserv] out: server starting
Without the && sleep 1, there's nothing in /tmp/pg.log (though the file is created), and no postgres processes are running. With the sleep, everything works fine.
(And if I execute the same command directly on target machine's command line, it works fine without the sleep.)
Since it's working, it doesn't really matter, but I'm asking anyway: Does someone know what the sleep is allowing to happen and why?
You might try also using the pty option set it to false and see if it's related to how fabric handles pseudo-ttys.