Roger Oberholtzer said the following on 07/18/2011 03:00 AM:
So, there is a flaw in the ntp start logic when the network interface on which it's server lives only becomes available some time after ntp starts. It seems never to re-check that a server that was initially not available later becomes available.
IMO, the problem is ntp, not the system start stuff. Since I have effectively removed my network from the system startup environment, I would find it hard to see that environment being able to solve ordering or dependency issues. How could a system service know that some user will, via their own non-system configuration, eventually, maybe start a network where an interesting server lives?
Your reasoning is valid, but it is also an example of a much more general problem, that of dependencies. You are stating, quite rightly, that NTP should be started when a specific network comes up. We've discussed a similar problem here recently, a function needing a wifi network but the "network up"of a wired network was allowing it to proceed. The real solution is a proper management of dependencies and triggers. I've said before that this is a situation that 'systemd' addresses; it was intended to address these kinds of dependencies. http://en.opensuse.org/SDB:Systemd http://en.wikipedia.org/wiki/Systemd http://fedoraproject.org/wiki/Features/systemd # zypper se systemd Loading repository data... Reading installed packages... S | Name | Summary | Type --+------------------+-------------------------------------+----------- | systemd | A System and Session Manager | package | systemd | A System and Session Manager | srcpackage | systemd-gtk | Graphical front-end for systemd | package | systemd-sysvinit | System V init tools | package # zypper info systemd Information for package systemd: Repository: mozilla Name: systemd Version: 18-1.2.4 Arch: i586 Vendor: openSUSE Installed: No Status: not installed Installed Size: 2.0 MiB Summary: A System and Session Manager Description: Systemd is a system and service manager, compatible with SysV and LSB init scripts for Linux. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux cgroups, supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic. It can work as a drop-in replacement for sysvinit. I have Fedora 15 running on one machine with systemd. As someone who has been using init scripts since SVR4 in the late 0s it feels ... well, weird, but somehow very logical. I keep feeing that I want DBUS and Cgroups to be better explained/documented. Th examples make sense but I'm find it hard to extrapolate about DBUS and Cgroups. Systemd itself is sooooo logical I keep asking 'why didn't someone do that a decade ago?' -- APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past: it creates a new generation of coding bums. -- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org