YWCA Hello's questions

I am trying to kill the redis-server process on macOS. Whenever I kill it or shut it down, it restarts under a different process id.

I've tried killing it three ways:

1. redis-cli shutdown
2. sudo kill [proc-id] : It's running as root for whatever reason, so sudo is needed.
3. brew services stop redis

I checked ~/Library/LaunchAgents/ and /System/Library/LaunchAgents/ for an applicable plist but none of the files contain redis, case insensitive search.

I also checked the "Users & Groups" section of the macOS control panel and do not see any entries under "Login Items" that are applicable.

The macOS console app reveals something interesting when I kill the process:

com.apple.xpc.launchd[1] (org.redis.redis-server): Service only ran for 8 seconds. Pushing respawn out by 2 seconds`

So it seems that it's registered and being watchdogged by launchd, but I can't figure out where the configuration is for the life of me.

launchctl list|grep -i redis does not reveal any results, either.

Thoughts?

I am running a Rails application server. My setup is:

• Apache 2, using mod_ssl for both https and ssl client certificates
• Phusion Passenger 5
• Rails 4
• Ruby 2.1

I use NewRelic to monitor the running application. I recently enabled monitoring for request queueing delay, mainly out of curiosity. I was surprised to find that the delay in the request queue is often as long or longer than the actual ruby code and database execution time. ~200 ms seems high, right?

Most online information indicates that this happens when the request queue is waiting for a worker to become available, but that isn't the case. As seen below, we're barely using our provisioned instances. During peaks, we rarely go above 30% utilization.

A few other notes:

• Apache and Passenger reside on the same server, so there is not a false timing issue due to system clocks being out of sync.
• Regarding SSL processing, Apache grabs the client SSL certificate and attaches it as a header in the request. The rails application then handles the rest of the processing.

What could be the issue here?

The backstory is that I am trying to debug an issue I am having with FreePBX currently. The channel variable REC_STATUS is set to RECORDING when it shouldn't be.

After quite a bit of troubleshooting and no sign of anything in the dialplan that could be causing this, I decided to insert a NoOp(${REC_STATUS}) as the first line of dialplan code to be executed for a new incoming call. Guess what? REC_STATUS is already set to RECORDING as of the first line of dialplan execution for these new calls.

My question is this: how is this channel variable already set before the dialplan starts executing?

We have a CentOS OS that became unresponsive this morning to external network traffic. It is a virtual machine. I was able to reboot the VM. After logging back in, I found the following in the /var/log/messages file, repeating over and over, up to the point of the reboot:

Jan 21 06:53:01 PBX kernel: audit: backlog limit exceeded
Jan 21 06:53:01 PBX kernel: audit: audit_backlog=321 > audit_backlog_limit=320
Jan 21 06:54:01 PBX kernel: printk: 8 messages suppressed.
Jan 21 06:54:01 PBX kernel: audit: audit_backlog=321 > audit_backlog_limit=320
Jan 21 06:54:01 PBX kernel: audit: audit_lost=1130 audit_rate_limit=0 audit_backlog_limit=320

I read on another forum that the following command could identify the source of the backlog traffic:

[root@PBX log]# aureport --start today --event --summary -i

Event Summary Report
======================
total  type
======================
486  USER_ACCT
486  CRED_ACQ
486  USER_START
485  LOGIN
477  CRED_DISP
477  USER_END
6  USER_LOGIN
3  USER_AUTH
2  CONFIG_CHANGE
2  CRED_REFR
1  DAEMON_START

Can anyone advise me as to what next steps I should take in preventing this issue from happening again? I'm not particularly familiar with the purpose of the backlog or what the output of the event summary report means.