On Tue, Apr 18, 2017 at 11:32:00AM +0100, KatolaZ wrote:
> On Tue, Apr 18, 2017 at 12:21:05PM +0200, Alessandro Selli wrote:
> > Why should a car driver care if the traffic light has the red or the
> > green light turned on?
> > Why should a sysadmin care if the OS he uses runs systemd or not?
>
> This is a totally wrong assumption. Being a sysadmin is all about
> setting and implementing *policies*. And the choice between systemd or
> anything else is exactly a matter of policy. So yes, a sysadmin *must*
> care if the OS he/she uses runs systemd or anything else.

I don't care whether the OS runs systemd, sysv-rc, openrc or an enslaved
young boy sitting at the console and starting daemons by hand. What I do
care about is whether it:
* implements standard interfaces
* is correct while doing so

My beef with systemd is that it has egregious bugs (some due to mistakes,
some due to intentional brain damage), and that working around bugs or
places where it doesn't meet your particular use case is a matter of a
single line of shell on sysv-rc but on systemd it's a hopeless case of
digging through a giant blob of spaghetti code.


A sample openrc (init script?) bug:

[ ok ] Asking all remaining processes to terminate...done.
Currently running processes (pstree):
init-+-2*[nbd-client]
     `-rc---openrc---openrc-run---sendsigs---pstree
[FAIL] Killing all remaining processes...failed.
Stopping NBD client process: 
disconnect, [17892.932316] block nbd0: NBD_DISCONNECT
sock, [17892.937274] block nbd0: shutting down sockets
done
disconnect, [17892.951774] block nbd1: NBD_DISCONNECT
sock, [17892.956734] block nbd1: shutting down sockets
done
rmmod: ERROR: Module nbd is in use
nbd-client.
[warn] not deconfiguring network interfaces: network devices still mounted. ... (warning).
[info] Saving the system clock.
[info] Hardware Clock updated to Tue Apr 18 13:18:23 CEST 2017.
[ ok ] Deactivating swap...done.
[....] Unmounting local filesystems...[17896.568144] block nbd0: Attempted send on invalid socket
[17896.573501] blk_update_request: I/O error, dev nbd0, sector 4257856
[17896.579804] block nbd0: Attempted send on invalid socket
[17896.585125] blk_update_request: I/O error, dev nbd0, sector 4258112
[17896.591402] BTRFS error (device nbd0): bdev /dev/nbd0 errs: wr 1, rd 0, flush 0, corrupt 0, gen 0
[17896.600422] block nbd0: Attempted send on invalid socket
[17896.605741] blk_update_request: I/O error, dev nbd0, sector 4262496
[17896.612018] block nbd0: Attempted send on invalid socket

A sysadmin who doesn't know the proper way to fix this can still trivially
deal with the issue. Don't know how to make nbd-client stop _after_ network
filesystems are unmounted? Just plop in a manual unmount somewhere. Here,
your system is fixed, you can then learn when you got a bit of time.


A sample systemd bug:

A common way to backup/search/etc a filesystem that has something mounted in
random subdirectories is to "mount --bind / /mnt/ref/rootfs; mount --bind
/home /mnt/ref/home" and so on, so you don't risk a naive script getting
into a loop. Except, systemd sometimes decides to convert that --bind into
a --rbind (specifically what you wanted to avoid!); it might happen a
fraction of second after the mount, several minutes or apparently never. So
you can't even rely on that bug happening or not. It will also sometimes
decide to _unmount_ what you just mounted (most often on a degraded raid).
Now try to work around this...

--
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄⠀⠀⠀⠀ preimage for double rot13!