Revision history for this message
We're seeing the same issue. This breaks a lot on running machines.
Revision history for this message
The root cause is the `action` parameter for the HTTP POST request to `localhost:
Revision history for this message
Status changed to 'Confirmed' because the bug affects multiple users.
| Changed in monit (Ubuntu): | |
| status: | New → Confirmed |
Revision history for this message
We are facing the same issue.
Revision history for this message
To confirm we are seeing this on all our servers which is causing quite a lot of problems for us. Details on how to roll this back would be welcome.
Revision history for this message
@henryoswald 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.
Revision history for this message
Same here, several automated servers affected.
Revision history for this message
Same here, this program broke a few things for me
Revision history for this message
Other actions are also affected:
$ monit restart tomcat
Invalid action "action=restart"
$ monit stop tomcat
Invalid action "action=stop"
$ monit start tomcat
Invalid action "action=start"
$ monit monitor tomcat
Invalid action "action=monitor"
$ monit unmonitor tomcat
Invalid action "action=unmonitor"
Revision history for this message
Is there any update to this?
Revision history for this message
we have the same problem here!
Revision history for this message
Same issue
```
01 Invalid action "action=stop"
01 Invalid action "action=stop"
```
Revision history for this message
We have the same problem. It's affecting several of our projects and causing issues with our deployment process.
Revision history for this message
For those of you using Chef with Ubuntu, the following worked for us as part of our deploy recipes:
package 'Install Monit 1:5.16-2' do
package_name 'monit'
version '1:5.16-2'
options '--allow-
end
Revision history for this message
As stated above you can roll back a version and it seems to be happy again.
sudo apt-get install monit=1:5.16-2
Revision history for this message
Same problem here, above workaround works for us too. Thanks!
Revision history for this message
Same problem here, @kschutt's workaround works here too. Thanks
Revision history for this message
Same problem here, Downgrading works fine.
Thanks @Jason Brodie
Revision history for this message
I'm seeing this issue as well. I believe the severity to be medium to high for the following reason:
- I have automatic security updates turned on, and I want to keep it that way
- I don't know of a way to pin the version of monit
- every morning my system upgrades monit to the bad version and I have to manually downgrade on multiple systems (Ansible makes it less painful, but human error is still a factor)
Revision history for this message
Jimmy: after you downgrade the monit package, you can pin it to the current version with command: `apt-mark hold monit`
Revision history for this message
@pschiffe Excellent suggestion thanks. I'll do that.
I will say, though, that now I have potential human error in the process of remembering to un-hold it when a fix for this package comes out. I can live with it, though.
Revision history for this message
Another option if you want to run the latest version: The pre-compiled generic monit package from the monit project works OK without this problem, but Ubuntu stores the config files in a non-default location so you have to specify the path to /etc/monit/monitrc with each command.
Revision history for this message
To add to my last comment, you can download the monit sourcecode here:
https:/
You can specify the non-default destination for the monitrc config file with this:
./configure --sysconfdir /etc/monit
./make
Then you can make this into a .deb file with:
checkinstall
Then you just `apt-get remove monit` to remove the bad monit installation and `dpkg -i monit_5.
So this version of monit will accept commands like `monit unmonitor all`, etc. However, running `systemctl restart monit` will not start the daemon.
Revision history for this message
Also encountered this issue, pschiffe solution seems to work temporarily for us.
Revision history for this message
There is unattended-upgrade running background and every its in `/etc/apt/
It does upgrade if
Unattended-
is available
you can comment
${distro_
if you check /var/log/
you can find monit is upgraded.
Revision history for this message
This bug is tormenting, my servers do not stop sending emails to me, to warn me of this bug.
I have crontab that warns me every 3 minutes about this errors like:
Invalid action "action=start"
Invalid action "action=monitor"
I tryed downgrad withi:
sudo apt-get install monit=1:5.16-2 -y --allow-downgrades
but without success :/
Revision history for this message
How could this BS pass QA? All monit commands are broken, so even the most simple test should have failed!
This patch breaks a lot of servers and the only current workaround is to downgrade to a vulnerable version and either pin that version or disable unattended security upgrades. But "Importance" is still "Undecided" and no fix in sight... WTF?
Revision history for this message
I think all the problem is in the latest CVE-2016-7067.patch which features this change like this:
- "%s",
+ "securitytoken=
+ token,
the %s comes from a var which already has an "action=" in it
I tried locally compile the package with a new patch with only this hunk:
--- monit-5.
+++ monit-5.
@@ -449,7 +449,7 @@ boolean_t control_
- "securitytoken=
+ "securitytoken=
And the resulting package seems to work ok for me. I didn't tested it extensively. Also I'm just playing with source code, I do not know how to submit a proper patch.
Revision history for this message
ansible plays to downgrade and place on hold:
tasks:
- name: downgrade monit
apt: name=monit=1:5.16-2 force=yes state=present
- dpkg_selections:
name: monit
selection: hold
Revision history for this message
Revision history for this message
The attachment "deduplicate 'action=' in CLI http request" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.
[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]
Revision history for this message
I have successfully pinned all my relevant systems to the working version of monit. Now I have a dilemma:
- Do I want to have a secure system, or
- Do I want to be able to use monit (thereby allowing me to deploy code, etc)
I don't know how exposed I am now. If I'm not exposed much, then it's not high severity for me. Does anybody have a sense of how risky it is to be running this older version of monit?
Revision history for this message
Revision history for this message
@theist Thanks, that helps.
Revision history for this message
It looks like theist provided a good patch. What is the next step necessary to get that patch integrated and release a new version? And about how long would that take? I'm debating whether I need to put in a better workaround on my servers, or if I can hold off until a fix is released. I'd even be willing to put in some effort to get this into a new version, but I have no idea what that entails.
Revision history for this message
Trying to make a decision if we make a change to our Chef scripts to make this workaround permanent as there isn't much activity on this bug. We are holding off automated deployments as we were hoping for a fix.
Any idea on when this patch by theist will make it in?
Revision history for this message
Revision history for this message
I am facing the same issue as well. Not with "all" command but with any service. e.g.
monit restart webserver
does not work now, it was working before.
Revision history for this message
I'm also affected for all the same reasons mentioned above. Would be good if Canonical could resolve this ASAP.
Revision history for this message
This is also affecting my company. We use monit on all boxes for process management and have had to pin on a downrev version.
Do we know if the package maintainer knows that this is an issue? Can we get some confirmation of that?
Revision history for this message
Confirmed it broke monit the same way on all our live 16.04 servers.
Also em unable to re-monitor service that once went un-monitored due to failure attempts.
Gives the dreaded:
`Invalid action "action=monitor"`
message.
Haven't yet tested how that affects general reportability and recovereability of affected systems however.
Revision history for this message
This makes zero sense.
I see this in the changelog:
monit (1:5.16-2ubuntu0.1) xenial-security; urgency=medium
* SECURITY UPDATE: CSRF vulnerability
- debian/
are no longer implemented for GET method and require CSRF
protected POST: _doaction, _viewlog
- CVE-2016-7067
-- Eduardo Barretto <email address hidden> Fri, 10 Aug 2018 12:24:19 -0300
but monit shows CVE 2016-7067 already patched long before then:
https:/
Revision history for this message
Is see that monit is up to 5.25.3
Updating to upstream would make more sense than doing a poorly written and untested backport to an ancient version.
Revision history for this message
Thanks for reporting this bug and helping make Ubuntu better.
I'm sorry this affected you all.
I would like you to ask the reporter and all the involved people in the thread to always include the last person listed as Maintainer for the package (you can check this in the debian/changelog) in the bug tickets, otherwise the tickets might never get the attention of those responsible for it and we want to support you all.
Thanks Nye Liu for adding me to the ticket!
As you may know packages in Universe are community based and we're trying to give them security updates from time to time. Regressions may happen from time to time, and this was the case here.
Updating to upstream is not always an option as there might be ABI and API changes.
For now the temporary solution (and every time you find a problem in a package) is to downgrade the package.
I will be taking a look at it from now on and will release an update as soon as possible.
| Changed in monit (Ubuntu): | |
| assignee: | nobody → Eduardo dos Santos Barretto (ebarretto) |
Revision history for this message
Revision history for this message
Has anyone seen the same problem in Trusty (Ubuntu 14.04)?
Revision history for this message
In our experience, Trusty appears to be fine - it is just Xenial that is affected.
Revision history for this message
Revision history for this message
| Changed in monit (Ubuntu): | |
| importance: | Undecided → High |
Revision history for this message
I've tested (on a single host) and early indications are that the issue is resolved. If I notice any bad stuff I will report back.
Revision history for this message
did some quick testing (also on a single host) and the "Invalid action" error is not appearing with the 1:5.16-2ubuntu0.2 version.
Revision history for this message
I've tried 1:5.16-2ubuntu0.2 and it looks to fix the reported issue - i.e., commands such as "monit status", "monit restart all", "monit restart all" work as intended, rather than producing the "Invalid action" error message
Revision history for this message
Thanks for testing the package and giving feedback!
I really appreciate it.
So based on your feedback and on my tests, we just released monit 1:5.16-2ubuntu0.2 to the repository.
It should be available for upgrade in a few minutes depending on the mirrors.
If you encounter any problems, please do report and add me to the ticket.
Thanks again!
| Changed in monit (Ubuntu): | |
| status: | Confirmed → Fix Released |
Revision history for this message
$ dpkg -l |grep monit
ii monit 1:5.16-2ubuntu0.2 amd64 utility for monitoring and managing daemons or similar programs
all those start, stop, monitor, unmonitor, restart actions against certain component is working fine just "monit restart all" is throwing this:
"cannot parse response"
Revision history for this message
Hi shaochieh.chiang,
I appreciate you taking the time to report it and helping make Ubuntu better.
My tests didn't give the "cannot parse response", and from the feedback received above, it appears that no one faced this so far.
So could you give more information?
Which are the steps to reproduce the message you see?
How easy can you reproduce it?
Thanks
Revision history for this message
Us that thrown by your code? Under what circumstances will that be thrown?
I'll sift through the logs and find out. Do you have a way to turn on
verbose logs?
Thanks,
Don
Eduardo dos Santos Barretto <email address hidden> 於 2018年10月8日 週一
下午9:55 寫道：
> Hi shaochieh.chiang,
>
> I appreciate you taking the time to report it and helping make Ubuntu
> better.
>
> My tests didn't give the "cannot parse response", and from the feedback
> received above, it appears that no one faced this so far.
>
> So could you give more information?
> Which are the steps to reproduce the message you see?
> How easy can you reproduce it?
>
> Thanks
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> Latest patch breaks command line 'restart all'
>
> Status in monit package in Ubuntu:
> Fix Released
>
> Bug description:
> Running 'monit restart all' on command line was working yesterday
> 13.8.2018 but after latest security patch was installed it gives an
> error 'Invalid action “action=restart”'
>
> Ubuntu 16.04.4 LTS
> monit:
> Installed: 1:5.16-2ubuntu0.1
>
> To manage notifications about this bug go to:
> https:/
>
Revision history for this message
from our /var/log/monit.log:
[UTC Oct 8 03:45:56] error : 'nginx' failed protocol test [HTTP] at [localhost]
[UTC Oct 8 03:45:56] error : Mail: No mail servers are defined -- see manual for 'set mailserver' statement
[UTC Oct 8 03:45:56] info : Adding event to the queue file /var/lib/
[UTC Oct 8 03:45:56] info : 'nginx' exec: /bin/bash
[UTC Oct 8 03:47:35] error : cannot parse response
[UTC Oct 8 03:47:40] info : 'strapd' stop on user request
[UTC Oct 8 03:47:40] info : Monit daemon with PID 629 awakened
[UTC Oct 8 03:47:40] info : Awakened by User defined signal 1
the following logs were produced right after I ran "monit restart all":
[UTC Oct 8 15:34:49] info : Processing queued event /var/lib/
[UTC Oct 8 15:34:49] error : Mail: No mail servers are defined -- see manual for 'set mailserver' statement
[UTC Oct 8 15:34:49] error : Alert handler failed, retry scheduled for next cycle
[UTC Oct 8 15:34:49] error : 'nginx' failed protocol test [HTTP] at [localhost]
returned status 404
[UTC Oct 8 15:34:49] error : Mail: No mail servers are defined -- see manual for 'set mailserver' statement
[UTC Oct 8 15:34:49] info : Adding event to the queue file /var/lib/
[UTC Oct 8 15:35:07] error : cannot parse response
is it from somewhere in your code?
Revision history for this message
Hi shaochieh.chiang,
Could you try to downgrade the package version as below:
sudo apt-get install monit=1:5.16-2
And see if you can reproduce the error?
I've also found this on monit bug tracker:
https:/
It might be related to what you're facing.
Revision history for this message
Hi Eduardo,
so we should roll back to 1:5.16-2 then? yes once rolled back that error is gone.
Revision history for this message
Hi shaochieh.chiang,
Thanks for getting back to me.
I still need more information, how many services, processes and so on are you monitoring?
Can you share your monitrc configuration?
Your log also contain errors from nginx ... have you tried to solve them?
I'm still not convinced that your problem is related to the "restart all" problem reported here.
The "cannot parse response" error message comes from util.c:2072 (Util_parseMoni
So I believe that there's some problem between your monit and nginx.
Since you are the only person reporting this problem so far, I also would like you to send the information directly to my email (you can get from my launchpad profile), as I am considering your problem as a different problem, not related to the main topic here.
And I don't want people to get confused by our discussion.
As soon as we get more information, we can open a new bug ticket here in launchpad to track your issue, or update this one if there's any relation.
Thanks
To post a comment you must log in.