4 ms·
OpenBSD: #!/bin/sh daemon="/usr/local/sbin/daemonx" . /etc/rc.d/rc.subr rc_cmd $1 Though, it's Korn shell, not Bash, I suppose. Reliable per-serv
by vezzy-fnord 11y ago
OpenBSD:
#!/bin/sh
daemon="/usr/local/sbin/daemonx"
. /etc/rc.d/rc.subr
rc_cmd $1
Though, it's Korn shell, not Bash, I suppose.
Reliable per-service logging was largely perfected by multilog.
Judging complexity by observing external configuration is nonetheless exceptionally naive. One must factor in how the key-value pairs are built into an internal representation and dispatched, which is where things become an issue. Non-deterministic boot order (man 7 bootup) is one of many undesirable trade-offs.
- justizin 11y ago> Non-deterministic boot order (man 7 bootup) is one of many undesirable trade-offs. Yeah, also something I found annoying with Upstart's induction into Ubuntu. A predecessor at a place I worked at with a huge amount of traffic installed Ubuntu 9 on all of our memcache servers, and we found on a handful of other machines installed with Ubuntu 9 that non-deterministic boot order would randomly cause them to fail booting, and it was a coin-flip whether that would be a one-off problem or a forever problem requiring a reinstall. When you have 4 8GB machines (this was some years ago) powering memcache for a billion requests a day you don't really want a power cycle to cause 25% cache misses for hours as you wrestle with hardware and boot config. :/
- vezzy-fnord 11y agoUpstart doesn't have a formal dependency system, instead it orders things based on named preconditions and postconditions called events. Though these can be used to fulfill ordering requirements, I'd wager the information wasn't granular enough for parallelization to be efficient. Actually the main problem is that a lot of modern systems do not make their dependency graphs well observable, but instead treat them as in-memory ephemera that are constantly recalculated and cannot e.g. be written to persistent storage as known-good checkpoints. This is one area where s6-rc gets it right. You have to compile a manifest of your service dependencies and consistently boot from that well-known state, so for any changes it must be regenerated. serel was an earlier example of a service dependency system and parallel launcher which directly had you specify the nodes and edges of a directed graph as an RDF manifest. Clever.
- deleted 11y ago[deleted]
- tedunangst 11y agoFor those who like to count lines, that's typically a whopping 9 line script, because it usually looks like: #!/bin/sh # # $OpenBSD: xdm,v 1.1 2011/07/07 18:42:17 robert Exp $ daemon="/usr/X11R6/bin/xdm" . /etc/rc.d/rc.subr rc_cmd $1
- protomyth 11y agofor completeness' sake, here is the longest startup script on my OpenBSD system: #!/bin/sh # # $OpenBSD: nsd,v 1.9 2014/12/29 11:17:05 ajacoutot Exp $ daemon="/usr/sbin/nsd-control" daemon_flags="-c /var/nsd/etc/nsd.conf" . /etc/rc.d/rc.subr rc_usercheck=NO rc_pre() { if ! [[ -f /var/nsd/etc/nsd_server.key || -f /var/nsd/etc/nsd_server.pem || -f /var/nsd/etc/nsd_control.key || -f /var/nsd/etc/nsd_control.pem ]]; then /usr/sbin/nsd-control-setup >/dev/null 2>&1 fi } rc_start() { ${rcexec} "${daemon} ${daemon_flags} start" } rc_check() { ${daemon} ${daemon_flags} status || return 1 } rc_reload() { ${daemon} ${daemon_flags} reconfig && ${daemon} ${daemon_flags} reload } rc_stop() { ${daemon} ${daemon_flags} stop } rc_cmd $1 37 lines of code (postgresql's weighs in at 33)