lldpcli can't lock socket, execute configuration on FreeBSD13.0-RELEASE

[BlueSpaceCanary]

Bug description

Can't load or modify configuration on FreeBSD13.0-RELEASE because lldpcli and lldpctl can't lock the shared socket (e.g. /var/run/lldpd.socket by default)

Steps to reproduce the problem

1. Either install binary via sudo pkg install lldpd or build via ports, both hit the bug on both my machines

2. Run lldpd -d

% sudo lldpd -d
[...]
2021-05-03T17:50:55 [WARN/lldpctl] cannot get lock on /tmp/lldpd.socket: Bad file descriptor
2021-05-03T17:50:55 [INFO/lldpctl] an error occurred while executing last command
2021-05-03T17:50:55 [WARN/lldpctl] cannot get lock on /tmp/lldpd.socket: Bad file descriptor
2021-05-03T17:50:55 [INFO/lldpctl] an error occurred while executing last command
2021-05-03T17:50:55 [WARN/lldpctl] cannot get lock on /tmp/lldpd.socket: Bad file descriptor
2021-05-03T17:50:55 [INFO/lldpctl] an error occurred while executing last command
2021-05-03T17:50:55 [WARN/lldpctl] cannot get lock on /tmp/lldpd.socket: Bad file descriptor
2021-05-03T17:50:55 [INFO/lldpctl] an error occurred while executing last command
2021-05-03T17:50:55 [WARN/lldpctl] cannot get lock on /tmp/lldpd.socket: Bad file descriptor
2021-05-03T17:50:55 [INFO/lldpctl] an error occurred while executing last command
2021-05-03T17:50:55 [INFO/lldpctl] lldpd should resume operations

Expected outcome

lldpcli should lock /var/run/lldpd.socket and execute configuration

Current outcome

No configuration changes from the default succeed, either via config file or via manual lldpcli

Additional information

• Output of lldpd -vv (for the pkg version):

 % lldpd -vv
lldpd 1.0.8
  Built on 2021-04-18T11:51:33Z

Additional LLDP features:    LLDP-MED, Dot1, Dot3, Custom TLV
Additional protocols:        CDP, FDP, EDP, SONMP
SNMP support:                yes
Privilege separation:        enabled
Privilege separation user:   _lldpd
Privilege separation group:  _lldpd
Privilege separation chroot: /var/empty
Configuration directory:     /usr/local/etc

C compiler command: cc  -Wunknown-warning-option -fdiagnostics-show-option -fdiagnostics-color=auto -pipe -Wall -W -Wextra -Wformat -Wformat-security -Wimplicit-fallthrough -Wfatal-errors -Wheader-guard -Wdocumentation -Winline -Wpointer-arith -fno-omit-frame-pointer -Wno-cast-align -Wno-unused-parameter -Wno-missing-field-initializers -Wno-sign-compare -fstack-protector -fstack-protector-all -fstack-protector-strong -fstack-clash-protection  -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -O2 -pipe  -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -std=gnu99  -isystem /usr/local/include
Linker command:     /usr/bin/ld  -Wl,-z,relro -Wl,-z,now    -fstack-protector-strong  -L/usr/local/lib

• Output of uname -sro:

FreeBSD 13.0-RELEASE

• More system details:
  -- Generic kernel
  -- Everything installed via pkg
  -- No weird build options or kernel tunables set or anything

• Snippet of truss lldpcli -u /tmp/lldpd.scoket output when trying to execute configure system hostname "Foo" while lldpd is running:

[lldpcli] # configure system hostname "Foo"
read(0,"configure system hostname "Foo""...,4096) = 32 (0x20)
access("/tmp/lldpd.socket",W_OK|R_OK)		 = 0 (0x0)
socket(PF_LOCAL,SOCK_STREAM,0)			 = 3 (0x3)
connect(3,{ AF_UNIX "/tmp/lldpd.socket" },106)	 = 0 (0x0)
fcntl(3,F_SETLKW,0x7fffffffd830)		 ERR#9 'Bad file descriptor'

(The -u /tmp/lldpd.socket was just to eliminate any possible strange interaction with OpenZFS, my /tmp is just a regular tmpfs but my /var is a ZFS dataset)

I don't have a FreeBSD12.x or FreeBSD11.x VM handy so I haven't had a chance to try on earlier releases, but the bug does manifest identically on 2 different FreeBSD13.0 installs, one a DigitalOcean VM and the other a physical machine. Sorry in advance if this is a known bug that was fixed since 1.0.8, I skimmed the recent commits quickly and didn't see anything but I may just have missed it.

EDIT: Just tried building from source with the 1.0.11 tarball & creating the /usr/local/var/run/lldpd chroot, still hit the same error

[vincentbernat]

It seems FreeBSD does not allow to place a lock on Unix sockets. As advisory locks require an open file descriptor, it is not even clear if they are expected to work on Unix sockets at all. A clean solution would be to lock another file, but we don't have the rights to build a lock in the same directory as the socket. An alternative would be to build the lock in /var/lock/{basename}.lck.

[vincentbernat]

Could you try the latest master?

[BlueSpaceCanary]

I had to sudo mkdir /usr/local/var/lock since it's not there by default on FreeBSD & git doesn't have the ports tree's patches to account for BSDisms, but once I did that the current master worked perfectly. Thanks for the help!

[vincentbernat]

Maybe I could use /var/lock by default. Is there a /var/lock in FreeBSD? Most things go in /usr/local, but maybe /var/lock is special.

[vincentbernat]

MacOS does not seem to have a directory for that either. I could just use /tmp but it looks like there should be a cleaner solution than putting random files on the filesystem and putting locks on them. I could switch to POSIX semaphores, but they will survive the process in case it gets killed.

[BlueSpaceCanary]

I'm not sure what the standard thing to do is. It seems like there may just not be a standard place:

% sudo find /var -name \*lock
/var/db/prometheus/lock
/var/run/rpcbind.lock
/var/spool/lock

%

[vincentbernat]

I have pushed another commit (a1c9d4b) where I put the lock in the same directory as the control socket.