Bro Error failed to read lock file [Errno] No such file or directory

[David]

All other services are running fine except for Bro.

I try to run broctl deploy as instructed along with diag, install, and start and all shows and
Error: unable to read lock file:
Error: Unable to get lock

Any idea what I can do?

[Wes]

Looks like it is described here:

https://github.com/bro/broctl/blob/master/BroControl/util.py

Have you tried restarting Bro or NSM services?

When were you trying to run deploy? Did you make changes to Bro's configuration?

Please attach the output of sudo sostat-redacted:
https://github.com/Security-Onion-Solutions/security-onion/wiki/MailingLists#include-sostat-redacted-output

Thanks,
Wes

[David]

I tried restarting the system and nsm with no luck (before I posted)

I was trying to run deploy after the error started as the system error suggested it.

This was a fresh install of SO on a VM them once I moved to a larger drive it broke.

I tried rerunning setup with no luck in resolving the issue.

[Wes]

David,

You could try taking a look here to see if it helps:

https://groups.google.com/forum/#!topic/security-onion/wB7tcxrb7aE

Thanks,
Wes

[David]

On Friday, April 1, 2016 at 12:01:04 PM UTC-4, David wrote:

Yeah, I read that and although it appears to be the same symptoms but slightly different.

sudo broctl check
Warning: broctl config has changed (run the broctl "deploy" command)
Error: failed to read lock file: [Errno 2] No such file or directory: '/nsm/bro/spool/lock'

Error: Unable to get lock

sudo broctl deploy
Error: failed to read lock file: [Errno 2] No such file or directory: '/nsm/bro/spool/lock'

[Wes]

Have you made any changes to the Bro configuration or any other files
in /opt/bro/?

Are there any running Bro processes?
pgrep -lf bro

If so, # Kill bro processes
sudo pkill -9 -f bro

# Verify they got killed
pgrep -lf bro

# Try bro again
sudo broctl check

Ref: https://groups.google.com/d/msg/security-onion/wB7tcxrb7aE/dgAi8csfNNAJ

Thanks,
Wes

[David J. Peck]

Answers inline

-----Original Message-----
From: securit...@googlegroups.com [mailto:securit...@googlegroups.com] On Behalf Of Wes
Sent: Friday, April 01, 2016 17:06
To: security-onion <securit...@googlegroups.com>
Subject: [security-onion] Re: Bro Error failed to read lock file [Errno] No such file or directory

On Friday, April 1, 2016 at 4:50:42 PM UTC-4, David wrote:
> On Friday, April 1, 2016 at 12:01:04 PM UTC-4, David wrote:
> > All other services are running fine except for Bro.
> >
> > I try to run broctl deploy as instructed along with diag, install,
> > and start and all shows and
> > Error: unable to read lock file:
> > Error: Unable to get lock
> >
> > Any idea what I can do?
>
> Yeah, I read that and although it appears to be the same symptoms but slightly different.
>
> sudo broctl check
> Warning: broctl config has changed (run the broctl "deploy" command)
> Error: failed to read lock file: [Errno 2] No such file or directory: '/nsm/bro/spool/lock'
> Error: Unable to get lock
>
> sudo broctl deploy
> Error: failed to read lock file: [Errno 2] No such file or directory: '/nsm/bro/spool/lock'
> Error: Unable to get lock

Have you made any changes to the Bro configuration or any other files in /opt/bro/?

Are there any running Bro processes?
pgrep -lf bro

no

If so, # Kill bro processes
sudo pkill -9 -f bro

# Verify they got killed
pgrep -lf bro

# Try bro again
sudo broctl check

I keep getting error "failed to read lock"

Ref: https://groups.google.com/d/msg/security-onion/wB7tcxrb7aE/dgAi8csfNNAJ

I have reinstalled several times.

I have mapped nsm to a HGFS share

Thanks,
Wes

--
Follow Security Onion on Twitter!
https://twitter.com/securityonion
---
You received this message because you are subscribed to a topic in the Google Groups "security-onion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/security-onion/NJ2jCd-2x8g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to security-onio...@googlegroups.com.
To post to this group, send email to securit...@googlegroups.com.
Visit this group at https://groups.google.com/group/security-onion.
For more options, visit https://groups.google.com/d/optout.

[Wes]

David,

Please post the output of 'sudo sostat redacted'
https://github.com/Security-Onion-Solutions/security-onion/wiki/MailingLists#include-sostat-redacted-output

Have you compared this to a test on a clean install (on a different machine) or compared your Bro configuration to a working installation?

Thanks,
Wes

[David J. Peck]

Hi Wes and thanks,

I did attach a redacted sostat in this thread.

So I have tried three times all fresh installs with the same results

I believe the issue is I am attempting to use a vmware shared folder mapped into the SO and mounted to NSM. I wanted to map 16TB NSM folder for SO

Because, it always breaks after I move NSM to the larger shared folder and not upon initial install.

On another system, I created another vmdisk of 8TB and moved NSM to that. Working great for the past two months.

I strongly believe it has to do with the vmware share /mnt/hgfs/* not initilaizing (mounting) in time for use. I struggled with this mounting issue last moth here.
https://groups.google.com/forum/#!searchin/security-onion/mount$20a$20share/security-onion/D_K_cqlQVsU/laftTFpfBgAJ

I used rclocal to mount the share as fstab was not giving me reliable mounts.

So I am up and running with a 8TB VM :)
Not using the entire 16TB I wanted :(

I will continue to test and report.

Suggestions on possibly archiving pcaps to another share that is not nsm maybe to use up space?

[Wes]

I apologize for not noticing the sostat output above. I did notice that the process sending snort alerts to sguild had failed in the provided output. Is this still in a failed state? If so, you might want to try troubleshooting this.

Futhermore, the number of ELSA buffers in the provided sostat may indicate that there is an issue with ELSA taking in or indexing logs. You may want to check /nsm/elsa/data/elsa/log/* for more clues.

However, it looks like you have moved onto another install and may no longer be experiencing these issues.

Other than editing the current netsniff-ng configuration, I cannot recommend any other method of archiving PCAPs to another partition/folder, as there are multiple functions built-in to SO to control the amount of PCAPs and disk usage for nsm logs (sensor-clean) as well as access these items for review by analyst. I would advise against doing so, and encourage you to plan for /nsm to contain a lot of data, therefore allocating appropriate storage for it.

Thanks,
Wes