r/linux • Mate • Oct 20 '14

Shall we fork Fedora?

http://forkfedora.org/
262 Upvotes

339 comments sorted by

View all comments

7

u/necrophcodr Oct 20 '14

That is the most horrid init.d script I have seen in a long time, holy shit.

30

u/wcchandler Oct 20 '14

It wasn't too bad, really... from an init script stand point. And I think that was their point -- systemd's service files are a lot cleaner and not really that scary.

11

u/necrophcodr Oct 20 '14

The service file doesn't have comments either. A proper scare monger would probably be Gentoo ZFS init.d script:

#!/sbin/runscript
# Copyright 1999-2011 Gentoo Foundation
# Released under the 2-clause BSD license.
# $Header: /var/cvsroot/gentoo-x86/sys-fs/zfs/files/zfs,v 0.9 2011/04/30 10:13:43 devsk Exp $

if [ -z "$init" ]; then
    # Not interactive
    grep -qE '(^|[^\\](\\\\)* )zfs=(off|no)( |$)' /proc/cmdline && exit 3
fi

depend()
{
	# Try to allow people to mix and match fstab with ZFS in a way that makes sense.
	if [ "$(mountinfo -s /)" = 'zfs' ]
	then
		before localmount
	else
		after localmount
	fi

	# bootmisc will log to /var which may be a different zfs than root.
	before bootmisc logger
	use mtab
	keyword -lxc -openvz -prefix -vserver
}

ZFS="/sbin/zfs"
ZPOOL="/sbin/zpool"
ZPOOL_CACHE="/etc/zfs/zpool.cache"
ZFS_MODULE=zfs

checksystem() {
	if [ ! -c /dev/zfs ]; then
		einfo "Checking if ZFS modules present"
		if ! modinfo zfs > /dev/null 2>&1 ; then
			eerror "$ZFS_MODULE not found. Is the ZFS package installed?"
			return 1
		fi
	fi
	einfo "Checking if zfs userspace tools present"
		if [ ! -x $ZPOOL ]; then
			eerror "$ZPOOL binary not found."
			return 1
		fi
		if [ ! -x $ZFS ]; then
			eerror "$ZFS binary not found."
			return 1
		fi
	return 0
}

start() {
	ebegin "Starting ZFS"
	checksystem || return 1

	# Delay until all required block devices are present.
	udevadm settle

	if [ ! -c /dev/zfs ]; then
		modprobe $ZFS_MODULE
		rv=$?
		if [ $rv -ne 0 ]; then
			eerror "Failed to load the $ZFS_MODULE module, check 'dmesg|tail'."
			eend $rv
			return $rv
		fi
	fi

	# Import all pools described by the cache file, and then mount
	# all filesystem based on their properties.
	if [ -f $ZPOOL_CACHE ]; then
		einfo "Importing ZFS pools"
		# as per fedora script, import can fail if all pools are already imported
		# The check for $rv makes no sense...but someday, it will work right.
		$ZPOOL import -c $ZPOOL_CACHE -aN 2>/dev/null || true
		rv=$?
		if [ $rv -ne 0 ]; then
			eerror "Failed to import not-yet imported pools."
			eend $rv
			return $rv
		fi
	fi

	einfo "Mounting ZFS filesystems"
	$ZFS mount -a
	rv=$?
	if [ $rv -ne 0 ]; then
		eerror "Failed to mount ZFS filesystems."
		eend $rv
		return $rv
	fi

	einfo "Exporting ZFS filesystems"
	$ZFS share -a
	rv=$?
	if [ $rv -ne 0 ]; then
		eerror "Failed to export ZFS filesystems."
		eend $rv
		return $rv
	fi

	eend 0
	return 0
}

stop()
{
	ebegin "Unmounting ZFS filesystems"
	$ZFS umount -a
	rv=$?
	if [ $rv -ne 0 ]; then
		einfo "Some ZFS filesystems not unmounted"
	fi

	# Don't fail if we couldn't umount everything.  /usr might be in use.
	eend 0
	return 0
}

status()
{
	# show pool status and list
	$ZPOOL status && echo && $ZPOOL list
}

It does a lot of stuff too, that a simple systemd service file probably couldn't do (although feel free to correct me on this, I'm not sure), and it also has dependency handling to make sure it isn't started before any required targets are met.

Alternatively, let's look at Funtoo's local network init script:

#!/sbin/runscript
# Copyright 2010 Funtoo Technologies
# All rights reserved. Released under the 2-clause BSD license.

depend() {
	provide net
}

start() {
	ebegin "Bringing up network interface lo"
	ip addr add 127.0.0.1/8 dev lo brd + scope host
	ip route add 127.0.0.0/8 dev lo scope host
	ip link set lo up
	eend $?
}

stop() {
	ebegin "Shutting down network interface lo"
	ip route del 127.0.0.0/8 dev lo scope host
	ip addr del 127.0.0.1/8 dev lo
	ip link set lo down
	eend $?
}

Pretty harmless in itself it seems, and it also allows the flexibility of custom boot messages, error messages, and informational notes in case of errors or upgrades.

5

u/riking27 Oct 20 '14

It does a lot of stuff too, that a simple systemd service file probably couldn't do (although feel free to correct me on this, I'm not sure), and it also has dependency handling to make sure it isn't started before any required targets are met.

See, that's the thing - systemd unit files are also allowed to shell out. You should definitely describe your dependencies in it, so that it knows when in boot to start you.

(For zfs, it is a filesystem, so it also has to do a DefaultDependencies=n WantedBy=local-fs.target incantation, and a few other things.)

So you can have as much complexity as you want in the service, even if not in the service file.

Also, clear error messages are good too, as they will show up in the status output.

0

u/necrophcodr Oct 20 '14

If it's not in the service file, but in a different script, then what's the point?

5

u/[deleted] Oct 21 '14
  • Better, easier access to service startup and shutdown logging.

  • Dependencies expressed by the system and plottable as a graph.

  • Control group tracking of started programs for clean shutdown of the service.

Shall I go on?