How do delete client with linefeed in client name?

I had an older version of Sensu where a linefeed was in the client name, and now I can’t delete the client.

When I go to the client’s page in Uchiwa to see its check results, I see all passing tests. When viewing the keepalive check, it’s also passing:

https://sensu_domain/#/client/Sensu/client_name

https://sensu_domain/#/client/Sensu/client_name?check=keepalive

However, when viewing all keepalive checks in Uchiwa at this URL:

https://sensu_domain/#/events?check=keepalive

I see “client_name” in the list of failing keepalives, however when I click that client name, it goes to this URL:

https://sensu_domain/#/client/Sensu/client_name%0A?check=keepalive

(Notice the extra “%0A” at the end of the URL)

And this keepalive check is passing. When I delete the “%0A” from the URL, it shows the exact same passing keepalive. So either way, it’s showing the keepalive of the corrected client.

This is all after the client name was fixed on that particular client, by updating /etc/sensu/conf.d/client.json and ensuring name doesn’t have any extra characters between the double-quotes, so there are definitely no more events coming in from clients with a linefeed in their client name.

I’ve tried deleting: “client_name” from the API which succeeds and regenerates the correct client, and “client_name%0A” which returns a 404.

I’ve also tried shutting down all Sensu servers, confirming that those processes aren’t running, then deleting all keys in Redis with client_name in them. There were never any keys with special characters in them, but I deleted all of them anyway.

After deleting the Redis keys, I reset the sensu-api and uchiwa processes, then started up the sensu-server processes.

But after all of this, the failing keepalive is still showing up in the list of failed keepalives and does the same stuff when clicked as mentioned above.

How can I fix this?

Nevermind, when you have Redis print its keys to the shell, it hides the “\n” character.

You have to delete them manually from within the redis-cli.

···

On Fri, Jun 17, 2016 at 11:53 AM Neil Hooey nhooey@gmail.com wrote:

I had an older version of Sensu where a linefeed was in the client name, and now I can’t delete the client.

When I go to the client’s page in Uchiwa to see its check results, I see all passing tests. When viewing the keepalive check, it’s also passing:

https://sensu_domain/#/client/Sensu/client_name

https://sensu_domain/#/client/Sensu/client_name?check=keepalive

However, when viewing all keepalive checks in Uchiwa at this URL:

https://sensu_domain/#/events?check=keepalive

I see “client_name” in the list of failing keepalives, however when I click that client name, it goes to this URL:

https://sensu_domain/#/client/Sensu/client_name%0A?check=keepalive

(Notice the extra “%0A” at the end of the URL)

And this keepalive check is passing. When I delete the “%0A” from the URL, it shows the exact same passing keepalive. So either way, it’s showing the keepalive of the corrected client.

This is all after the client name was fixed on that particular client, by updating /etc/sensu/conf.d/client.json and ensuring name doesn’t have any extra characters between the double-quotes, so there are definitely no more events coming in from clients with a linefeed in their client name.

I’ve tried deleting: “client_name” from the API which succeeds and regenerates the correct client, and “client_name%0A” which returns a 404.

I’ve also tried shutting down all Sensu servers, confirming that those processes aren’t running, then deleting all keys in Redis with client_name in them. There were never any keys with special characters in them, but I deleted all of them anyway.

After deleting the Redis keys, I reset the sensu-api and uchiwa processes, then started up the sensu-server processes.

But after all of this, the failing keepalive is still showing up in the list of failed keepalives and does the same stuff when clicked as mentioned above.

How can I fix this?