error: invalid action action= restart monit
Server Info
Ubuntu 16.04.4 LTS
monit:
Installed: 1:5.16-2ubuntu0.1
This issue is for these monit commands
$ monit restart tomcat
$ monit stop tomcat
$ monit start tomcat
$ monit monitor tomcat
$ monit unmonitor tomcat
Reason:
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in monit (Ubuntu):
status: New → Confirmed
for the time being, you need to revert the monit package to 1:5.16-2, try manually in a server with
sudo apt-get install monit=1:5.16-2
If your servers are automatically provisioned with some third party tool (chef, puppet, bash scripts, etc) then you would need to update them accordingly.
Source: https://bugs.launchpad.net/ubuntu/+source/monit/+bug/1786910
NOTE
In case you're facing this issue again even after downgrading Monit version, please blacklist it from unattended-upgrades service. It runs daily to fetch latest security updates for relative packages.
To blacklist monit, open "/etc/apt/apt.conf.d/50unattended-upgrades" and under "Unattended-Upgrade::Package-Blacklist" block, add "monit".
#TomDavies suggested a better solution than blacklisting, see the comments.
Do remember it to remove from blacklist once the issue is solved.
You would need to run the above command again to revert back to older patch.
This is an extension to answer given by Ninad.
If you are using Chef to automatically configure your servers, then the following code change will help you install the previous version of monit in all your servers running Ubuntu 16.04
if 'ubuntu' == node['platform'] && '16.04' == node['platform_version']
Chef::Log.info "******** Installing monit version '1:5.16-2' ********"
execute 'apt-get -y install monit=1:5.16-2 --allow-downgrades'
else
Chef::Log.info "******** Installing latest monit ********"
package 'monit'
end
Make sure to revert this once the bug is fixed.
Related
I have been deploying my service on App Engine for a long time now and never had an issue until today.
Command to Deploy
gcloud app deploy app.yaml
Output
Beginning deployment of service [default]...
Building and pushing image for service [default]
ERROR: gcloud crashed (ModuleNotFoundError): No module named 'distutils.spawn'
I just deployed this morning with no issues and randomly when I tried to redeploy now I get the above error. Hopefully someone can help figure out what caused this issue.
For info:
app.yaml
runtime: custom
env: flex
manual_scaling:
instances: 1
resources:
cpu: 1
memory_gb: 4
disk_size_gb: 10
Gcloud version
$ gcloud --version
Google Cloud SDK 341.0.0
alpha 2021.05.14
beta 2021.05.14
bq 2.0.68
core 2021.05.14
gsutil 4.62
minikube 1.20.0
skaffold 1.23.0
I had a similar issue, on my case this was the solution:
sudo apt-get install python3-distutils
Same exact problem.
Building and pushing image for service [default]
ERROR: gcloud crashed (ModuleNotFoundError): No module named 'distutils.spawn'
This issue seemed to be in the snap install of google-cloud-sdk in Ubuntu 20.04.2 LTS (You can select it pre-installed during the ISO setup.. DONT)
I was getting this in 18.04 as well
FINALLY solved it..
But.. I had to make sure I did not snap install google-cloud-sdk
I also..
sudo apt update
sudo apt upgrade
Then I made sure the snap install was not installed. (After a fresh install of Ubuntu). Sense I use dockerfiles it's easy for me to zap a dev environment and get it back.
But Id imagine if you can't zap your os and make sure not to let the OS put it's snap install of google-cloud-sdk.. You could snap remove google-cloud-sdk and then hunt for all it's configuration files.. And remove them.
At that point
https://cloud.google.com/sdk/docs/install#deb
Follow that... I did so exactly... FINALLY seemed to work. I used the apt install route they explain.. NOT the snap.
I tried all the pip install sudo apt-get install python3-distutils Till I was blue in the face... NADA.
somehow.. The Snap being present puts PATH settings that use the wrong distutils.
On my box now that I search for it.. In Totally fresh OS state... No Snap install and going through exactly the cloud.google.com/sdk/docs/install#deb work..
Here is distutils everywhere on my box in Ubuntu 20.03.2 LTS
$ sudo find / -name distutils
/snap/lxd/19188/lib/python2.7/distutils
/snap/core18/1944/usr/lib/python3.6/distutils
/snap/core18/1944/usr/lib/python3.7/distutils
/snap/core18/1944/usr/lib/python3.8/distutils
/usr/lib/python3.8/distutils
/usr/lib/python3.9/distutils
/usr/lib/python2.7/distutils
Note.. There's no google-cloud-sdk in the snap!!
The gcloud app deploy FINALLY works!! Passes the part where it starts to deploy.
But as the others in this.. It happened completly random.
All I can guess is...... Something clobered distutils as an update somewhere and started pointing to a garbage path.
Make sure you search for distutils find out where it is.. what's referencing it.. Somewhere in that mess you can fix it.
One thing I was able to discover is this problem will come default from 20.04.2.
I downloaded the most recent iso.. thinking it was an 18.04 issue.
Installed it fresh into Virtual Box.. And got exactly this same issue. So my solution fix (no SNAP).. Is against a totally clean 20.04.2 brand spanking new Ubuntu LTS VM. Default everything.
===============
Regarding the random one day it worked.. the next it didn't...
Here's the thing about snaps in Ubuntu:
https://www.google.com/search?q=Do+snap+packages+update+automatically%3F&rlz=1C1CHBF_enUS834US834&ei=ygynYJGRIo3f-gSLzb3YDg&oq=Do+snap+packages+update+automatically%3F&gs_lcp=Cgdnd3Mtd2l6EAMyCAghEBYQHRAeUJ-TCVifkwlgj5kJaABwAXgAgAFziAHVAZIBAzEuMZgBAKABAqABAaoBB2d3cy13aXrAAQE&sclient=gws-wiz&ved=0ahUKEwiRnrfXz9nwAhWNr54KHYtmD-sQ4dUDCA4&uact=5
"Do snap packages update automatically?
Snaps update automatically, and by default, the snapd daemon checks for updates 4 times a day. Each update check is called a refresh."
so that's how it randomly broke if you used a snap
I am installing Postgres on CentOS 7 boxes, and that part itself is fine. The issue that someone brought up is that they would like for my install script to try and not depend on the service name being postgresql-10, and instead just use postgres or postgresql. Either one would be fine. Well I noticed that there is a flag --servicename that can be used, but I am unsure where to use it in the process. I have tried a few times but it doesn't seem to work.
Note that this is how I am installing postgres
yum -y install $LINK
yum -y install postgresql10
yum -y install postgresql10-server
/usr/pgsql-10/bin/postgresql-10-setup initdb
systemctl enable postgresql-10
systemctl start postgresql-10
the $LINK up there is just the path to pull from the Postgres website. Again, the ideal situation would be for me to specify the service name such that I can standardize that and limit script changes when Postgres versions change.
Note that I found out about the --servicename flag in this, link but I am not completely sure how to apply that to the installation above. It does appear that the link is more for installing on windows, but I would assume we could do the same thing in a Linux installation. Any suggestions here would be welcome.
The link that you found is about EnterpriseDB's installer for Windows, and the service mentioned is a Windows service. That won't help you on CentOS.
The name of the systemd service file is hard-wired into the RPM, but there is nothing that prevents you from creating your own service file in /etc/systemd/system and using that one instead. Then you can choose whatever name you prefer. You can just copy the service file from the RPM as a starting point.
Renaming the file or creating one in /usr/systemd/system is not a good idea, because that will mess with RPMs.
postgresql-10 is a good name for the service, however. If you choose postgres or something else that doesn't contain the version, what will you do once you want to install v11?
To answer your question: There is no way to configure the name of the service when installing it via RPM.
I created a machine in AWS Cloud9 and I want to install timescale on that instance. I have previously installed and setup postgres 9.6 using yum.
OS version is:
Amazon Linux AMI release 2018.03
.
When I run 'which pg_config', it is found here:
/usr/bin/pg_config
Looking at the install instructions on the timescale website, I came up with this:
sudo yum install -y
https://download.postgresql.org/pub/repos/yum/9.6/redhat/rhel-6-x86_64/pgdg-ami201503-96-9.6-2.noarch.rpm
wget
https://timescalereleases.blob.core.windows.net/rpm/timescaledb-0.9.2-postgresql-9.6-0.x86_64.rpm
sudo yum install timescaledb-0.9.2-postgresql-9.6-0.x86_64.rpm
after the last command I get the following error:
Running transaction Installing :
timescaledb-0.9.2-0.el7.centos.x86_64
1/1 ERROR: Could not find pg_config, expected it at
/usr/pgsql-9.6/bin/pg_config. Please fix and try again.
warning: %post(timescaledb-0.9.2-0.el7.centos.x86_64) scriptlet
failed, exit status 1 Non-fatal POSTIN scriptlet failure in rpm
package timescaledb-0.9.2-0.el7.centos.x86_64
Do you have any more details on how you installed PostgreSQL on CentOS? I suspect this may have something to do with a mismatch between your pg_config installation and your PostgreSQL 9.6 installation, similar to the user in this issue.
I'd recommend uninstalling your current postgresql-devel and explicitly installing it for 9.6:
yum install postgresql96-devel
It seems the AMI is setup a bit differently than a normal CentOS install so PostgreSQL is installed in a different place than our installer expected. I've gone ahead and updated the RPMs to use a more robust method of finding the correct place to put the files. If you could re-download the latest RPM and confirm that it works that'd be great.
I've met exactly the same problem.
I solve this by manually linking them together.
sudo ln -s /usr/lib64/pgsql96/bin/pg_config /usr/pgsql-9.6/bin/pg_config
"Yum install monit" command by default will install 5.14 version. But Monit has released till 5.20 version
I tried with the below command for available packages
sudo yum --showduplicates list monit | expand
It shows up only one available package
Available Packages
monit.x86_64 5.14-1.el6
Are there any other option apart from manually downloading the tar using wget command and then installing it.
There used to be an RPM on the rpmforge/repoforge repos although these are presently down.
I believe these might resurface (based on this https://github.com/repoforge/rpms/issues/375) but in the mean time unless you want to build your own RPM for it you could grab this from a mirror.
Such as:
yum install https://www.insaneworks.co.jp/pub/el6/RPMS/x86_64/monit-5.20.0-1.el6.x86_64.rpm
On a centos 7 I installed redis using the regular wget, make and make install commands.
While I am able to do a command
$redis-server redis.conf
and it works nicely.
But if I try
systemctl start redis-server
or
sudo service redis-server start/restart
it says
Failed to issue method call: Unit redis-server.service failed to load: No such file or directory.
How can I fix this. I need to run redis-server as a service.
You can try:
sudo systemctl enable redis-server
sudo service redis-server start
You can check that redis or redis-server right. May be You need to restart Your System after sudo systemctl enable redis-server
It would be better to install Redis via an RPM (package) rather than just performing a wget of the sources and building them. You might find a suitable version in the "extra packages for Enterprise Linux" EPEL collection. Just add the appropriate repositories to your Yum configuration and use yum commands to update your package indexes and query them to see if you have the Redis server version you're interested in. Here's a guide on How to install redis server on CentOS 7 / RHEL 7 using EPEL
Another option would be to build your own RPM using a .spec file. Rather than trying to write your own from scratch you might try something like remicollet/remirepo's redis.spec as a starting point (for version 3.0.7) or search around for other RPMs or .spec files. However the big deal is that you need the redis.service and redis.init configuration files that are used to describe how to run a Redis server to the systemd system.