conf/164048: /etc/rc.d/hostid is not symlink aware

[Dirk-Willem van Gulik]

On 12 jan. 2012, at 17:48, Matthew Story wrote:

> On Thu, Jan 12, 2012 at 3:15 AM, Dirk-Willem van Gulik <dirkx at webweaving.org> wrote: 
> [...snip] 
>       # If ${hostid_file} already exists, we take UUID from there.
> -       if [ -r ${hostid_file} ]; then
> +       # If ${hostid_file} already exists, we take UUID from there. We use
> +       # a -f rather than a -r check as the histid_file may in fact be
> +       # a symbolic link.
> 
> per the test man-page, `-r' tests for readability, regardless of type, and `-f' tests for the existence of a regular file.  `-r' does include an implicit test for existence, so `-r' will in fact work for symlinks, and fail reliably if the symlink source_file does not exist (relevant bits from the test man-page at the bottom of this message):
….
> with this patch, if ${hostid_file} exists, and is non-readable, cat ${hostid_file} will fail, and yield no $1 to hostid_set (effectively identical to a hostid_file that is empty).  this is not the desired behavior:

Totally understood - but wanted to stay close to the behavior of dhclient-script as I understand it.  And this happens to also make the behavior of /etc/rc.d/sshd on first run the same. Keep in mind that one can always set the rc variable.
...
> This line is actually why you are seeing a hostid_file on restart.  The hostid_file does not exist on your system, and per the comment, and implementation, if a hostid_file does not exist, one is generated and set via sysctl (via the hostid_set function).

Agreed - as _set is better.

> There is a small race condition in this file (unless rc.d is doing some locking on hostid_file in the caller)
….

Right - which in this case is one we should not worry about - this is during boot - as the rc.d files are ran one by one; and generally not twice. However - the lock issue does affect  /sbin/dhclient-script - and I've seen this behaviour there in the wild.

Dw