Nicolas Williams wrote: >> Cron jobs look a lot like services that are loops with "sleep" in them. >> (Sleep(1) or sleep(3), your choice :-) > > I don't agree: the status of each execution of the "loop body" minus the > sleep is tracked separately.
Depends on whether your loop has a "&" in it too. (Personally, I think that the iterations are independent is more of a bug than a feature, having seen systems driven to their knees by cron jobs that ran longer than their repeat period. Still, it's something that could be controllable.) Sure, cron is more complicated than a "sleep" loop, but inetd with TCP Wrappers is more complicated than bind()+listen(), too. >> Inetd-based services are, OTOH, kind of weird that they can be "online" >> with nothing running, and that they can have multiple contracts... > > It suffices that the port is open and the actual daemon can and will run > if a client connects. Sure, just as a cron job would presumably be "online" if it'll run when its time comes. Heck, inetd doesn't even use the normal "start" and "stop" methods. Neither inetd nor cron exactly match the "true" service semantic, but both are close enough that they can be fit in. If there wasn't expected to be this kind of variation in what "service" and "start" means, why would there be the concept of multiple restarters? >> ... and that's the reason that SMF has multiple restarters, so that >> there can be multiple policies for when and how things get started. > > I think cron jobs are sufficiently different. You might keep lots of > SMF affectations (repositories, service names, instance names, property > groups, properties, values, and soon, enhanced profiles and even > templates), but authorization and the UIs (among other things?) will be > sufficiently different to warrant a new type of FMRI. > > It's probably not that hard to add such a thing. I can see cron having > its own svc.configd repository (with mods for doing authorization > somewhat differently than SMF), for example, and a simplified API > layered atop libscf; plus svcs/svccfg/svcprop-like UIs, plus Visual > Panels support. That sounds like a whole Goodyear store worth of reinvented wheels... I don't deny some desire for specialist UIs, just as you presumably want a specialist UI for inetd-style jobs, one that displays port and protocol information. The rest... so far, I don't see it. Here's a thought experiment that might help: how would one extend SMF to support per-user services? Suppose I want to run my "foo" program all the time; how would that fit into SMF? Suppose that I want to run mydaemon on port 12345? (If your reaction is that normal users aren't allowed to do such things, note that it's pretty easy to do them with cron today, and in fact RHEL5 cron has specific support for "run at reboot".) Once we've got the per-user-service extension, cron jobs start to fit in even better.
