Create dhclient pid directory if it doesn't exist

[crees]

Summary

• Upgrading from older FreeBSD versions can result in errors
• /var/run can be a tmpfs, and this should be handled correctly

dhclient is hard-coded to use _dhcp and falls back to nobody if
that user doesn't exist, so mimic that behaviour here.

Test Plan

Reboot- works, and creates the dir correctly

[crees]

Hi Mark,

This was a problem starting with D16584- this is an easy fix.

Would you mind if I asked you to review/approve? Happy to find someone else if this is cheeky.

Chris

[markj]

libexec/rc/rc.d/dhclient

56

If the directory is created according to the mtree specification, it'll be owned by root:wheel. In particular, dhclient drops privileges after it creates a pidfile. Why does the rc script need to deviate from what we'd get with a clean install?

[crees]

You're quite right. I don't know why my /var/run/dhclient is owned like
that!

[markj]

Thanks, I think this is ok. I would suggest adding a short comment explaining why we create the piddir there.

It's also not obvious to me why dhclient itself shouldn't create the directory, but I think this is a reasonable solution, assuming you intend to merge to 13.0.

[crees]

I don't think daemons usually create piddirs- this is very common in ports land. Usually it's because they don't have permission for /var/run, so I guess they can't, but it's certainly not out of the ordinary.

I'll commit with this comment:

1. /var/run/dhclient is not guaranteed to exist,
2. e.g. if /var/run is a tmpfs

Thanks for taking the time to review.

[markj]

In D28843#646232, @crees wrote:

I don't think daemons usually create piddirs- this is very common in ports land. Usually it's because they don't have permission for /var/run, so I guess they can't, but it's certainly not out of the ordinary.

I'll commit with this comment:

1. /var/run/dhclient is not guaranteed to exist,
2. e.g. if /var/run is a tmpfs

Thanks for taking the time to review.

That sounds reasonable to me, thank you.