Refactor monitor and implment devd monitoring for freebsd #41
Conversation
wardn
changed the title
wardn
force-pushed
the
bsd_devd
branch
2 times, most recently
from
35cb475
to
ee34ebc
Compare
wgengine/monitor/monitor_freebsd.go
Outdated
| func NewConn() (Conn, error) { | ||
| conn, err := net.Dial("unixpacket", "/var/run/devd.seqpacket.pipe") | ||
| if err != nil { | ||
| log.Fatal("Dial error", err) |
There was a problem hiding this comment.
Return an error, don't log.Fatal from here.
(this is another thing we're bad at in this codebase right now, but libraries shouldn't fatally exit)
There was a problem hiding this comment.
Totally agree... I missed it when porting over some proof of concept code. I've made the change.
| } | ||
|
|
||
| func NewConn() (Conn, error) { | ||
| conn, err := net.Dial("unixpacket", "/var/run/devd.seqpacket.pipe") |
There was a problem hiding this comment.
Does this unix socket always exist on freebsd? Or is it possible for devd to not be running on a well-behaved system?
I don't know freebsd much, so I'm trying to answer: is it reasonable to assume failure here is a serious "oh crap" error?
There was a problem hiding this comment.
To be honest, I didn't have any experience with devd before this implementation, but it seemed like the shortest path to getting it up and running on my box. I'll look into it more, but I figure it's probably better to get some semblance of "working" and iterate from there. I'm happy to drop the _freebsd part of the monitor implementation with this commit and maintain it in my own fork if there's concerns with perceptions on platform support. Let me know.
There was a problem hiding this comment.
No concerns on platform support, just trying to make sure that the freebsd port is as robust as possible. I don't know how freebsd systems are set up, so I was asking about it :)
man devd says:
The devd utility is a system daemon that runs in the background all the time.
So it sounds to me like that open call should not fail on a normally working system - and so we don't need to make extra effort to recover from this just yet.
Signed-off-by: wardn <wardn@users.noreply.github.com>
I've refactored the monitor code to use a connection interface that's implemented by the architecture-specific builds.