SysVinit 2.90 Released With Fixes & Better Support For Newer Compilers

[Bsdisbetter]

https://docs.oracle.com/cd/E23824_01...451/dzhaq.html

Nothing like being wrong. SMF is running in background watchdoging services and will even email you if they fail. Really SMF scope is basically the same as systemd PID1 like it or not. Just you don't see it when you trace PID1 because PID1 is a stub. Yes make a few zombies and watch the solaris PID 1 not clean that up. In fact when monitoring SMF you see that it cleans it up. Systemd could look the same if someone decide to be underhanded and add a feature to kernel to redirect zombie pick up and made a stub PID1 that job is basically just start systemd as what solaris PID1 is these days for SMF,

It isnt a watchdog on pid 1 it's invoked by init. Big difference. i misssd the typing with the tablet.if systemd woild run as seperate process as i said earlier then it would msrginally be better.

[oiaohm]

It isnt a watchdog on pid 1 it's invoked by init. Big difference. i misssd the typing with the tablet.if systemd woild run as seperate process as i said earlier then it would msrginally be better.

When I say stub. Everything that would normally go to PID1 is in fact redirect to SMF. Zombie clean up, message to PID1 .... Basically its a slide of hand. SMF under solaris was first planed to be PID1. Big paying contract people complained and they made a stub that effectively there was a process at PID1 but it basically does nothing. PID1 on solaris is just start SMF and redirect everything to it. SMF then starts all services and monitors them and responed to all messages you would think are going to PID1. SMF PID number is made kernel panic as well as PID1. So you know have two PID running that can crash the system. So effectively no different to if it had been left as PID1 in the first place.

Really a stub on PID1 that just redirects everything and then assigned to what it loads kernel painic if what I just loaded failed is no improvement. Its just a change that makes people feel good. SMF vs systemd no much difference. Not being PID1 would make a difference if this mean that SMF could be restarted by PID1 if it crashed or the like but that is not the case. It would be nice if PID1 was a watchdog on systemd and able to restart it if it locked up this would be progress.

Basically you don't want systemd developers coping the under handed stunt the solaris developers did.