Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


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

[Discuss] SysVinit vs. systemd



On 9/13/2014 9:28 AM, Edward Ned Harvey (blu) wrote:
> But if you want to create something new, the ability to daemonize
> any-random-command is a really nice convenience factor; you just
> write any simple console application or shell script, and it behaves
> exactly the same on your command terminal as it does when you make it
> a service under systemd.

While I usually agree with what you write, I don't this time around. Any
random console tool /can't/ act the same as a daemon and as a console
tool. UNIX and Linux don't work that way. Try reading from stdin and
watch your daemonized console tool wait forever for input that will
never arrive. Silly example but it demonstrates that your claim about
behavior does not hold up to even silly levels of scrutiny.


> An active system will notice mysqld died, recognize that it's not
> supposed to do that right now, and restart it.  I know SMF will try

Which is a stupid way to run in production. There's a reason why the
daemon died. That reason needs to be identified so that corrective steps
can be taken. Blind restarts can obfuscate this information, can cause
damage to data, and can exacerbate existing damage.

> to restart a failed service some configurable threshold number of
> times in a configurable threshold period of time, and if the service
> continually fails, then the service gets disabled.  I assume
> something similar exists for systemd. 

I assume nothing about system and process startup procedures. These are
too important to trust to assumptions.

-- 
Rich P.



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org