Skip to content
  • Thomas Haller's avatar
    core: refactor loading machine-id and cache it · 83083112
    Thomas Haller authored
    Previously, whenever we needed /etc/machine-id we would re-load it
    from file. The are 3 downsides of that:
    
     - the smallest downside is the runtime overhead of repeatedly
       reading the file and parse it.
    
     - as we read it multiple times, it may change anytime. Most
       code in NetworkManager does not expect or handle a change of
       the machine-id.
       Generally, the admin should make sure that the machine-id is properly
       initialized before NetworkManager starts, and not change it. As such,
       a change of the machine-id should never happen in practice.
       But if it would change, we would get odd behaviors. Note for example
       how generate_duid_from_machine_id() already cached the generated DUID
       and only read it once.
       It's better to pick the machine-id once, and rely to use the same
       one for the remainder of the program.
       If the admin wants to change the machine-id, NetworkManager must be
       restarted as well (in case the admin cares).
       Also, as we now only load it once, it makes sense to log an error
       (once) when we fail to read the machine-id.
    
     - previously, loading the machine-id could fail each time. And we
       have to somehow handle that error. It seems, the best thing what we
       anyway can do, is to log an error once and continue with a fake
       machine-id. Here we add a fake machine-id based on the secret-key
       or the boot-id. Now obtaining a machine-id can no longer fail
       and error handling is no longer necessary.
    
    Also, ensure that a machine-id of all zeros is not valid.
    
    Technically, a machine-id is not an RFC 4122 UUID. But it's
    the same size, so we also use NMUuid data structure for it.
    
    While at it, also refactor caching of the boot-id and the secret
    key. In particular, fix the thread-safety of the double-checked
    locking implementations.
    83083112