I'm using Rundeck 3.2.6-20200427 and set up a job for installing packages.
Because rundeck runs noninteractive I need to preset some parameters for installing packages (in my case iptables-persistent).
Before installing the package I run that command (for now only this parameter, I will use more parameters if I got that working):
echo iptables-persistent iptables-persistent/autosave_v4 boolean false | sudo debconf-set-selections
Unfortunatelly I got that error if I run rundeck-command
09:09:08 debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable
09:09:08 Failed: NonZeroResultCode: Remote command failed with exit status 1
I'm absolute sure that there are no other task or running dpkg related process.
~$ lsof /var/cache/debconf/config.dat
~$
If I try to run that command directly, it works without any error. So I don't understand, why it is not working with rundeck.
I tried that on freshly installed host where I try to install packages (Ubuntu Server 20.04).
Here is my job definition: https://pastebin.com/YSu545tX
I found out that in the node-file, there was a typo so the job was running on wrong host and there were an apt-process, which was stuck.
There I checked with that command:
~$ sudo fuser -v /var/cache/debconf/config.dat
USER PID ACCESS COMMAND
/var/cache/debconf/config.dat:
root 5563 F.... frontend
Then I killed that process and corrected the node-file. Now it works.
I meet the same problem, but both 'fuser' and 'lsof' show nothing. finally finds out is dpkg lock that file, and use
ps aux | grep dpkg
to find that process and kill it.
Related
I am a beginner so please someone should show me kindness by showing me how to resolve my issue as a student. I've installed vagrant on git bash but every command seems to be telling me bash : vagrant command not found even vagrant halt is not working. please what do I do???
I wanted to install docker engine so i started by installing vagrant with git bash. Everything was successful so I tried
sudo yum install docker
The answer was: no command found
Then I tried sudo -i to get to the root and run the command again. Answer was bash : vagrant command not found
From here on all commands I try give me the same answer. I even tried to force vagrant halt but the same answer comes out.
If you receive an error that Vagrant is not found, try logging out and logging back in to your system (particularly necessary for Windows). $ vagrant Usage: vagrant [options] [] -v, --version Print the version and exit.
I'm using Ubuntu (VERSION="20.04 LTS (Focal Fossa) on Windows 10. Itried to install Docker.
I'm following the Docs from docs.docker.com:
I run the two commands:
$ curl -fsSL https://get.docker.com -o get-docker.sh
$ sudo sh get-docker.sh
When I run the second command it return an error:
Warning: apt-key output should not be parsed (stdout is not a terminal)
gpg: can't connect to the agent: IPC connect call failed
I looked in internet I found that some links trying to resolve the issue but in vein.
gpg: can't connect to the agent: IPC connect call failed
https://michaelheap.com/gpg-cant-connect-to-the-agent-ipc-connect-call-failed/
Someone have a suggestion please ?
Thanks
The temporary workaround mentioned on the issue thread at https://github.com/microsoft/WSL/issues/5125#issuecomment-625985191 worked for me. Run the commands
wget https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/lp1871129/+files/libc6_2.31-0ubuntu8+lp1871129~1_amd64.deb
sudo dpkg --install libc6_2.31-0ubuntu8+lp1871129~1_amd64.deb
sudo apt-mark hold libc6 #to avoid further update
Edit: /var/lib/dpkg/info/libc6:amd64.postinst and remove the sleep 1 like so:
Change this:
To this:
I couldn't start my ansible server installed in Centos/7 yet the installation works properly, any help plz
[vagrant#ansible-server ~]$ sudo systemctl status ansibled
Unit ansibled.service could not be found.
[vagrant#ansible-server ~]$ sudo systemctl start ansibled
Failed to start ansibled.service: Unit not found.
Ansible is not a Linux system Service. The command you are using is use for any service which is install on the linux. Just use Ansible command to run your playbook or adhoc command.
I am having a problem while trying to decrypt some keys using GPG. The following output is given to me:
gpg: can't connect to the agent: IPC connect call failed
I already edited some files, pointed in this tutorial: https://michaelheap.com/gpg-cant-connect-to-the-agent-ipc-connect-call-failed/ but with no success.
Possible reasons for that?
Even I had the above issue in Ubuntu 20 WSL, I tried all the below | above suggestions, but none worked for me.
root#7400-9888K13:/mnt/c/Users/PKammari# wget -q -O - https://packages.cloudfoundry.org/debian/cli.cloudfoundry.org.key | sudo apt-key add -
gpg: can't connect to the agent: IPC connect call failed
What did I do to resolve the issue?
remove gpg
install other version of gpg.
How do I do it?
apt remove gpg ( follow the instructions)
apt install gnupg1 (follow the instructions)
Option 2.
sudo apt update --y
`sudo apt remove gpg`
`sudo apt-get update -y`
`sudo apt-get install -y gnupg1`
Proof. (refer to the screenshot):
There is probably already a gpg-agent running on the system, which your gpg command is unable to connect to.
If you do a pkill -9 gpg-agent and then source <(gpg-agent --daemon) to restart the agent, you should be able to connect to the pinentry-curses for inputting your password.
In my case the agent wasn't even started. This is what I did to resolve:
C:\Program Files (x86)\gnupg\bin>gpg-connect-agent -v
gpg-connect-agent: no running gpg-agent - starting 'C:\Program Files (x86)\gnupg\bin\gpg-agent.exe'
gpg-connect-agent: waiting for the agent to come up ... (5s)
gpg-connect-agent: connection to agent established
> ^Z
Afterwards the commands to the agent started working.
To hopefully add to preetam's excellent answer above for those very new to this.
To install gnupg1 - if you get the error "Package gnupg1 is not available, but referenced....."
sudo apt remove gpg
sudo apt-get update -y
sudo apt-get install -y gnupg1
For me, previous responses worked, but partially, what made the magic in my case was a combination of all, see the commands below.
If you get error add-apt-repository: command not found, then, install package software properties common.
sudo apt remove gpg
sudo apt-get update -y
sudo apt-get install -y gnupg1
# In case of Error when adding "ppa" with message: add-apt-repository: command not found
sudo apt-get install software-properties-common
# Now, the hack
sudo add-apt-repository ppa:rafaeldtinoco/lp1871129
sudo apt update
wget https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/lp1871129/+files/libc6_2.31-0ubuntu8+lp1871129~1_amd64.deb
sudo dpkg --install libc6_2.31-0ubuntu8+lp1871129~1_amd64.deb
sudo apt-mark hold libc6 #to avoid further update
# Edit: /var/lib/dpkg/info/libc6:amd64.postinst and remove the sleep 1 that is in nearly the last line.
apt-get install -y gnupg gnupg1
cp -a /usr/bin/gpg /usr/bin/gpg2
ln -sf /usr/bin/gpg1 /usr/bin/gpg
apt-key worked for me after executing those commands.
I'm WSL 2.0 with Ubuntu 20.04 (Windows 10 Build 2004).
Reason:
uninstalling gnupg (2.x) also uninstalls gpg-agent, which is required.
installing gnupg1 (1.x) will install only gpg binary, not gpg-agent.
Both are required to work, but we want gnupg1 (1.x) to be the default "gpg" command (despite working with 2.x support-tools).
Based upon other behaviors in my Windows 10 system and through experimentation, I believe sometimes Windows Defender blocks gpg-agent from running because of a Windows Defender bug that slows the system trying to access low-level CPU counters.
Read Windows Defender can Significantly Impact Intel CPU Performance, We have the Fix. Work around the issue by downloading Counter Control from TECHPOWERUP and clicking "Reset Counters" when this problem arises. (See below.)
In my case I would frequently get the following error while trying to sign JAR files for deployment to Maven Central.
gpg: can't connect to the gpg-agent: IPC connect call failed
gpg: keydb_search failed: No agent running
gpg: skipped "…": No agent running
gpg: signing failed: No agent running
Sometimes if I kept trying over and over and over, eventually it would succeed.
Based on other answers, when this happened I trying manually connecting to the gpg-agent, but even that would time out:
> gpg-connect-agent --verbose
gpg-connect-agent: no running gpg-agent - starting 'C:\\Program Files (x86)\\GnuPG\\bin\\gpg-agent.exe'
gpg-connect-agent: waiting for the agent to come up ... (5s)
gpg-connect-agent: waiting for the agent to come up ... (4s)
gpg-connect-agent: waiting for the agent to come up ... (3s)
gpg-connect-agent: waiting for the agent to come up ... (2s)
gpg-connect-agent: waiting for the agent to come up ... (1s)
gpg-connect-agent: can't connect to the gpg-agent: IPC connect call failed
gpg-connect-agent: error sending standard options: No agent running
Because I've been experiencing similar slowdown issues on my machine seemingly related to Windows Defender, I ran "Counter Control" and sure enough, it showed that Windows Defender was maxing out the counter access as described in the article above. (Image embedded from the article.)
I tried to manually connect to gpg-agent again, but this time I hit "Reset Counters" in the utility just as gpg-connect-agent was retrying. When I did this, it immediately connected!
> gpg-connect-agent --verbose
gpg-connect-agent: no running gpg-agent - starting 'C:\\Program Files (x86)\\GnuPG\\bin\\gpg-agent.exe'
gpg-connect-agent: waiting for the agent to come up ... (5s)
gpg-connect-agent: connection to the agent established
This seems unlikely to be a coincidence that it would connect at just the moment I reset the counters. Moreover Windows Defender has been causing other slowdown problems on my machine.
I believe that buggy behavior of Windows Defender is causing this problem on my machine. Please investigate and report if you can reproduce this workaround. (Note that, as per the article, this problem only affects certain generations of Intel CPUs.)
Update: Upon further testing, I'm still getting can't connect to the gpg-agent even if I've already reset counters to prevent Windows Defender from hogging the CPU as explained above. For some reason I normally still have to manually run gpg-connect-agent. Now it may be that resetting the counters while gpg-agent was trying to connect allowed it to connect. And it could still be be that Windows Defender is stopping gpg-agent from connecting when my system starts up. But at this moment all I know is that 1) gpg-agent isn't starting up automatically, 2) I have to run gpg-connect-agent manually, and 3) even running gpg-connect-agent will time out unless I reset the CPU counters to stop Windows Defender from hogging the CPU.
Mine is a windows machine, and when I do git commit I get the following message. I have already configured gpg keys on my machine.
gpg: can't connect to the gpg-agent: IPC connect call failed
gpg: keydb_search failed: No agent running
gpg: skipped "BBB42EB62E25E8EB33AE2E65F40A504840B1C66B": No agent running
gpg: signing failed: No agent running
error: gpg failed to sign the data
fatal: failed to write commit object
Will Buffington answer worked for me.
I had to apply the command
gpg-connect-agent -v
repeatedly as shown below. And it worked in the third attempt.
Once the I get the message connection to agent established, I now ran the commit command again. Now its successful. Note the -S flag to sign my commits.
Update
This morning, it did not start even after 3 attempts. I had to double click the exe from its installed location.
I had the same problem. In my case, the gpg config files were somehow corrupted. To solve it, I have removed all the configurations inside ~/.gnupg (make sure to backup any keys that you still need). Then I have reinstalled gpg and everything worked well.
On WSL1 Ubuntu 20.04 following workaround available: https://github.com/microsoft/WSL/issues/5125#issuecomment-619097534
sudo add-apt-repository ppa:rafaeldtinoco/lp1871129
sudo apt update
sudo apt install libc6=2.31-0ubuntu8+lp1871129~1 -y
sudo apt-mark hold libc6
I had to use:
sudo apt autoremove gpg gnupg1 gnupg2
In windows subsystem Ubuntu 20 works these steps:
sudo apt remove gpg
sudo apt-get update -y
sudo apt-get install -y gnupg1
After that steps appear "Ok"
I had the same problem when I killed the agent. It was not able to connect to agent again. So I had to remove all gpg gpg-related packages, and reinstall. I had to remove gpg-agent as well.
so what I did
sudo apt remove gpg gpg-agent
sudo apt-get install -y gpg
I was able to connect without installing new software. In my case the issue was that the IPC file wasn't in the expected position.
Check if gpg-agent with ps -eaf | grep gpg is running and kill it if it is running with killall gpg-agent
Start gpg-agent with verbose
$ gpg-agent --daemon -v
...
GPG_AGENT_INFO=/tmp/.../S.gpg-agent; export GPG_AGENT_INFO
copy-paste the GPG_AGENT_INFO line, including the export, in the shell where you need the agent.
I am trying to setup a queue listener for laravel and cannot seem to get supervisor working correctly. I get the following error when I run supervisorctl reload:
error: <class 'socket.error'>, [Errno 2] No such file or directory: file: /usr/lib/python2.7/socket.py line: 228
The file DOES exist. If try to run sudo supervisorctl I get this
unix:///var/run/supervisor.sock no such file.
I've tried reinstall supervisor and that did not work either. Not sure what to do here.
I'm running Laravel Homestead (Ubuntu 16.04).
Result of service supervisor status:
vagrant#homestead:~/Code$ sudo service supervisor status
● supervisor.service - Supervisor process control system for UNIX
Loaded: loaded (/lib/systemd/system/supervisor.service; enabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: exit-code) since Thu 2016-12-22 11:06:21 EST; 41s ago
Docs: http://supervisord.org
Process: 23154 ExecStop=/usr/bin/supervisorctl $OPTIONS shutdown (code=exited, status=0/SUCCESS)
Process: 23149 ExecStart=/usr/bin/supervisord -n -c /etc/supervisor/supervisord.conf (code=exited, status=2)
Main PID: 23149 (code=exited, status=2)
You should run sudo service supervisor start when you are in the supervisor dir.
Worked for me.
2020 UPDATE
Try running sudo service supervisor start in your terminal before using the below solution. I found out that the issue sometimes occurs when supervisor is not running, nothing complicated.
I am using Ubuntu 18.04. I had the same problem and re-installing supervisor did not solve my problem.
I ended up completely removing the conf.d directory and recreating it with new configs. Make sure you back up your configurations before trying this:
sudo rm -rf /etc/supervisor/conf.d/
sudo mkdir /etc/supervisor/conf.d
sudo nano /etc/supervisor/conf.d/my-file.conf
Copy+Paste your configuration into your new file.
sudo supervisorctl reread started working again.
In Ubuntu 18.04 with distribution's package
You probably did the same mistake as me an created the config file /etc/supervisord.conf while my service manager (systemd) was using the config file /etc/supervisor/supervisord.conf
Solutions
Remove the config file created
sudo rm /etc/supervisord.conf
Move it to the correct location
sudo mv /etc/supervisord.conf /etc/supervisor/supervisord.conf
Now you can run sudo supervisorctl
Why?
when you run supervisorctl it first searches for the config file located at /etc/supervisord.conf, if it's not present, it will search for the package's default file /etc/supervisor/supervisord.conf this is the one systemd actually runs.
Systemd always use the file /etc/supervisor/supervisord.conf regardless of the other file's existence.
You can check which file is using systemd by running sudo systemctl status supervisor
You can see in the last line the command where the config file is hardcoded
I had a very similar problem (Ubuntu 18.04) and searched similar threads to no avail so answering here with some more comprehensive answers.
Lack of a sock file or socket error is only an indicator that supervisor is not running. If a simple restart doesn't work its either 1. not installed, or 2. failing to start. In my case nothing was being logged to the supervisor.log file for me to know why it was failing until I ran the following command (-n to run in foreground) only to find out that there was a leftover configuration file for a project that had been deleted that I missed.
/usr/bin/supervisord -n -c /etc/supervisor/supervisord.conf
Once I deleted the bad/leftover file in the conf.d folder and started it back up with sudo service supervisor start everything worked.
Here are some comprehensive steps you can take.
Is supervisor installed? dpkg -l | grep supervisor If not reinstall sudo apt install supervisor
Are all instances of supervisor stopped? systemctl stop supervisor Lingering supervisor processes can be found ps aux | grep supervisor then kill -9 PID.
Is supervisor.conf in the right location /etc/supervisor/supervisor.conf and there are no syntax errors? Reinstall from package would correct this.
Move your specific files in conf.d/ temporarily out of the folder to try and start with no additional config files. If it starts right up sudo service supervisor start the likelihood of an error in your project .conf file exists.
Check status with sudo service supervisor status.
Move your .conf files one by one back into conf.d/ and restart sudo service supervisor restart. Be sure to check with sudo service supervisor status between. If it fails you know which .conf file has an issue and can ask for specific help.
check everything is running with supervisorctl status and if not start with supervisorctl start all.
None of about answers helped me.
the problem was i didn't follow supervisor documentation.
and a step i didn't do was run echo_supervisord_conf command that makes the configuration file.
Steps i did for Ubuntu 18.04:
Installing supervisor (without pip):
sudo apt-get install supervisor
echo_supervisord_conf > /etc/supervisord.conf (with root access: first run sudo -i then echo_supervisord_conf > /etc/supervisord.conf)
change python dependency to python2
(Depends: python-pkg-resources, init-system-helpers (>= 1.18~), python-meld3, python:any (<< 2.8), python:any (>= 2.7.5-5~)
in these files: /usr/bin/supervisord | /usr/bin/supervisorctl | /usr/bin/echo_supervisord_conf.
Just change the first line from #!/usr/bin/python to #!/usr/bin/python2
run supervisord
Finish
hope help !
Facing the python file not found an error, code=exited, status=2 once I try with the official document but still same.
I have tried so many solutions for my laravel application.
But at last, I have tried with my solution.
Here is an example for the code :
[program:dev-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/html/example.com/artisan queue:work --sleep=3 --tries=3
autostart=true
autorestart=true
user=ubuntu
numprocs=8
redirect_stderr=true
stdout_logfile=/var/www/html/example.com/storage/logs/laravel.log
stopwaitsecs=3600
Ref: https://laravel.com/docs/7.x/queues#supervisor-configuration
I ended up just removing supervisor entirely, reinstalling and rewriting my config files. I must have just done something wrong in the process and wasn't able to catch it.
You can try by removing all of the related folder of supervisor & uninstall supervisor completely.
sudo rm -rf /var/log/supervisor/supervisord.log
sudo rm -rf /etc/supervisor/conf.d/
After doing this, reinstall supervisor by
sudo apt install supervisor
Now, you can run correctly. Check with
sudo systemctl status supervisor
If by running sudo service supervisor status you get the following:
ExecStart=/usr/bin/supervisord -n -c /etc/supervisor/supervisord.conf (code=exited, status=2)
Try running /usr/bin/supervisord, it will give you clear message to tell you where the error is.
On Centos 7 I use the following...
supervisord -c /path/to/supervisord.conf
followed by...
supervisorctl -c /path/to/supervisord.conf
This gets rid of the ".sock file not found" error. Now you have to kill old processes using...
ps aux|grep gunicorn
Kill the offending processes using...
kill <pid>
Then again...
supervisorctl -c /path/to/supervisord.conf
Supervisor should now be running properly if your config is good.
Check the supervisord.conf file.
Look for the following:
[unix_http_server]
file=/path/to/supervisor.sock/file ; (the path to the socket file)
chmod=0700 ; sockef file mode(default 0700)
Go to the path mentioned above and check if the file is present.
If it is present then try re-installing supervisor.
If not then search for supervisor.sock file either using the command line or file explorer GUI.
Copy the file found in the above step to the location specified in the [unix_http_server] by using the cp command or GUI.
For me, the supervisor.sock was present in the /run folder.
you can try
sudo touch /var/run/supervisor.sock
sudo chmod 777 /var/run/supervisor.sock
I ran into this issue because we were using supervisorctl to manage gunicorn. The root of my problem had nothing to do with supervisor (it was handling other processes just fine) or the python sock.py file (file was there, permissions were correct), but rather the gunicorn config file /etc/supervisor/conf.d/gunicorn.conf. This configuration file was managed by a source-controlled template with environment variables and when we updated the template on the server, the template variables were never replaced with the actual data. So for example something in the gunicorn.conf file read user={{ user }} instead of user=gunicorn. When supervisor tried to parse this config when running supervisorctl start gunicorn it would crash with this socket error. Repairing the gunicorn.conf file resolved the supervisor issue.
Source of answer : http://supervisord.org/installing.html
Run command : echo_supervisord_conf
Once you see the file echoed to your terminal, reinvoke the command as echo_supervisord_conf > /etc/supervisord.conf. This won’t work if you do not have root access.
If you don’t have root access, or you’d rather not put the supervisord.conf file in /etc/supervisord.conf, you can place it in the current directory (echo_supervisord_conf > supervisord.conf) and start supervisord with the -c flag in order to specify the configuration file location.
The error should've been resolved by now.
I did the following to solve the issue on CentOS Linux 7
sudo systemctl status supervisord.service
With the above command, I realise that the program was in active
sudo systemctl start supervisord.service
Now I use the command above to start the service and everything works well now