tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: How Unix manages processes in userland

On Dec 8, 10:17pm, David Holland wrote:
} On Sun, Dec 08, 2013 at 01:56:25PM -0800, John Nemeth wrote:
}  > } > } Heh - you know, you are close to describing the Solaris SMF (service
}  > } > } management facility)...
}  > } > 
}  > } >      If we're serious about service management, then something like
}  > } > that, or a similar facility from another OS is most likely what we
}  > } > need.  Using something that already exists, if a suitable one can
}  > } > be found, would probably be a good thing.
}  > } > 
}  > } >      In the above, I didn't even get into the issue of dependencies.
}  > } >   [...]
}  > } >      Doing service management properly can quickly get quite complex,
}  > } > which is a good reason to use something that already exists [...]
}  > } 
}  > } Given the infrastructure we already have (for dependencies and other
}  > } things), trying to splice in third party code is not a good idea.
}  > 
}  >      What infrastructure?  We don't do service management.  Our
}  > rc.d startup code does not count as service management.
} It is what we have and it handles dependencies, starting and stopping;
} regardless of whether it's adequate as it is, bolting on something
} else that doesn't interoperate with it would be a serious mistake.

     A proper service management facility would replace it.  The
only real question is would things like rc.conf be kept (rc.d files
might be used for dependency information, but generally aren't
suitable for real service management).  There is no reason why rc.d
should be sacrosanct.  It has served as well as a replacment for
a monolithic /etc/rc, but it doesn't adequately satisfy modern
service management.

     On that score, I disagree with the idea that service management
should be a plug-in where one can drop in any number of different
service monitors.  This way lies madness, as it would difficult
for a random admin to figure out how to administrate a random system
(I realise this may not happen a lot in the NetBSD world, but it
is something that we should thing about), and it would be near
impossible for a package that wants to install a service to figure
out what it should do.  Service management really needs to be part
of the base system.

}-- End of excerpt from David Holland

Home | Main Index | Thread Index | Old Index