Docker taking ages to start

[snaens]

For a long time I had no idea why the docker daemon on all out robots was taking so long to boot up.
This was a serious problem, as rebooting a robot after a critical failure would take minutes of precious competition time.
Turns out it's because of us using systemd-networkd for CAN setup!

How I came across this problem:

internetted "linux service slow start", execute suggested command

snaens@snaens-dev:~ $ systemd-analyze critical-chain
Bootup is not yet finished (org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0).
Please try again later.
Hint: Use 'systemctl list-jobs' to see active jobs

huh, that's odd, what's the holdup?

snaens@snaens-dev:~ $ systemctl list-jobs 
JOB  UNIT                                 TYPE  STATE  
92   docker.service                       start waiting
100  systemd-networkd-wait-online.service start running
125  rc-local.service                     start waiting
119  getty.target                         start waiting
135  systemd-update-utmp-runlevel.service start waiting
106  rpc-statd-notify.service             start waiting
1    multi-user.target                    start waiting
120  getty@tty1.service                   start waiting
94   network-online.target                start waiting

9 jobs listed.

Hold up, everything is waiting for systemd-networkd-wait-online.service?!
I enabled systemd-networkd for our automagic CAN setup!
helpful: https://www.baeldung.com/linux/systemd-networkd-wait-online-service-timeout-solution
ok, two options:

1. Hack systemd-networkd-wait-online.service to not do the timeout thingy
2. Set up CAN some other way

Fixing it

I first chose Option 2: doing it the way Prof. May did it in edu_drive_ros2 - with udev rules.
But unlike his approach, I really didn't wanna construct some intricate mess of services, so I simply made udev run the commands.
/etc/udev/rules.d/99-EduArt_canbus.rules

KERNELS=="spi0.0", SUBSYSTEMS=="spi", DRIVERS=="mcp251xfd", ACTION=="add", NAME="CAN0", RUN+="/sbin/ip link set CAN0 up type can bitrate 500000"
KERNELS=="spi0.1", SUBSYSTEMS=="spi", DRIVERS=="mcp251xfd", ACTION=="add", NAME="CAN1", RUN+="/sbin/ip link set CAN1 up type can bitrate 500000"
KERNELS=="spi1.0", SUBSYSTEMS=="spi", DRIVERS=="mcp251xfd", ACTION=="add", NAME="CAN2", RUN+="/sbin/ip link set CAN2 up type can bitrate 500000"

But soon I realized that naming is necessary, as the names are random by default.
And with udev you can't use original, lowercase letters, as they clash with each other when they get
renamed one after another.
Plus, I'd have to make another config for Bento-Box's usb-based CAN comms.

---

So I went back to Option 1.
I suppose systemd-networkd somehow takes ids and stuff into account, as the CAN names are always the same.
We modify the service with sudo systemctl edit systemd-networkd-wait-online.service and add this content:
(what the linked website suggested)

###editing blablabla

# override timeout to be 1 second
[Service]
ExecStart=
ExecStart=/usr/lib/systemd/systemd-networkd-wait-online --timeout=1

###editing blablablubb

This creates a file under /etc/systemd/system/systemd-networkd-wait-online.service.d/override.conf.
I copied it to the robot repos, and changed the setup scripts to install it back.
Fixed!