The linked criticism of SMF [1] suggests that the author tried really hard to use the XML-based declarative configuration. I'm pretty sure that the things he accomplished with those commands are straight-forward <dependency> and/or <dependent> elements in the appropriate manifest. Like with systemd that came later, a sysadmin can copy a system-provided manifest from /usr/... to /etc/..., modify it, then apply it to get the new configuration. That being said, some higher level tooling would be helpful, and many SMF users [2] [3] developed such tools.
I was a lead sysadmin of a thousand or so Solaris 10+ systems for about 5 years (2005 - 2010), then a Solaris developer for a few years before I ventured into SMF commands like "delpg". I'm pretty sure it wasn't until I was doing some work on the intersection of zones, install, and SMF (sysconfig, sys-unconfig, and related manifests) that I felt I even needed to have that level of understanding.
I strongly disagree that SMF wasn't a good system. I agree that some aspects of its UI weren't good, and that since in the beginning the Greenline team didn't model shutdown dependencies, shutdown for a long time wasn't fast. But the fundamentals of SMF were and remain solid, and they're really not that different from launchd and systemd, but predated systemd by a lot:
- services as defined in some declarative
language (XML, which isn't great is is what
was reasonable in 2005)
- services are imported into a database
(SQLite2, because at the time SQLite3 was
barely in existence)
- distinguish persistent and temporary
disabling of services (same as Windows)
- restarter takes care of everything (no more
accidental inheritance of wrong environ when
restarted by hand)
- process contracts (in Linux: cgroups) as a
process grouping mechanism that allows related
service processes to be monitored and killed
together
- link to FMA (fault management)
Looking at TFA's opinions, I found this: https://utcc.utoronto.ca/~cks/space/blog/linux/BashLocaleScr... -- but is it Bash or is it libc? Because I think it's libc. And yes, it's awful. But we have to place fault at the right feet. Just as with TFA's opinion about SMF, where IMO it's important to characterize the issues correctly.
SysV init has the ability to "respawn" a single PID, which I have used in the past (principally, replacing HP ServiceGuard clustering):
xy:3:respawn:/usr/bin/return_to_life
If the above process exits to much, the syslog will record "return to life respawning too quickly; disabled for 5 minutes."
This is all much more pleasant in systemd, which can understand and restart a whole group of processes, even when the parent process exits in the course of startup.
I was a lead sysadmin of a thousand or so Solaris 10+ systems for about 5 years (2005 - 2010), then a Solaris developer for a few years before I ventured into SMF commands like "delpg". I'm pretty sure it wasn't until I was doing some work on the intersection of zones, install, and SMF (sysconfig, sys-unconfig, and related manifests) that I felt I even needed to have that level of understanding.
1. https://utcc.utoronto.ca/~cks/space/blog/solaris/SMFNotGoodI...
2. https://cuddletech.com/2008/04/smf-manifest-generator/
3. https://github.com/timotheosh/Manifold