blinkd.service: Disable on wheatley

[donald]

blinkd.service interfers with special code run (via ssh) on wheatley
which makes its led device mirror the status of the led device near the
chipreader at the main entrance.

Disable blinkd.service on wheatley.

[wwwutz]

yuck! hidden in a service file ... somewhere in the abyss of systemd... /etc/systemd/.. /lib/systemd/ /var/systemd/... do I need to reload... whatever. this will likely work and fix https://github.molgen.mpg.de/mariux64/mariux64-issues/issues/9 , thanks

[donald]

Oops, I forgot about the issue. Mental overload... Here I just targeted the "blinkd should not run wheatley" problem. What you suggested in mariux64/mariux64-issues#9 included "starting an alternative daemon on a specific host". Which, I think, is not needed immediately , as the update is done via ssh from another system not from another daemon, right?

[wwwutz]

Starting an alternative daemon would be much more flexible. something like -e /etc/blinkd.d/daemon-${HOST} && exec /etc/blinkd.d/daemon-${HOST} would allow to echo /bin/true > /etc/blinkd.d/daemon-wheatley to disable it. ( pathes are just example ). these daemons do not need systemd-process control and resource management. they are writen properly by default.

[donald]

these daemons do not need systemd-process control and resource management. they are writen properly by default.

The only existing daemon, blinkd, does not demonize (double-fork away from the caller, maybe setsid() , detach tty, detach from callers pam session, reopen standard file descriptors ...). We wanted 'blinkd' to be activated when a led device is plugged in, which means via udevd. You can't run a non-terminating command from udev rules directly , you need a "start daemon" command to call when the device appears.

Anyway, lets merge that for now, so we don't get wring lights on wheatley, and leave mariux64/mariux64-issues#9 open to add host-specific daemon?

[wwwutz]

yup!