in reply to How not to implement updaters

It's admin day again.

I tried to update the bugtracker one more time, with a new idea from who-knows-where. "Just delete that plugin in the filesystem and re-install it later via the user interface" said the knowledge base article. That should cure some problem we did not have last time I tried. Guess what: After some wasted hours, the bugtracker is once again f-ed up beyond repair, restore the backup.

Completely unrelated, systemd running as process 1 (a.k.a. init) on our fileserver decided to crash, complain loudly on the console how evil the world is, disconnected from /dev/initctl and dbus, and made the entire server refuse to reboot. Yeah, stuffing everything and the kitchen sink into init sounds completely natural and sensible to about one human on earth. What could possibly go wrong? A sane init looks different: Re^14: CPAN failed install.

No, I won't change the installation to get rid of systemd. I don't want to be the only one who knowns how to work with our servers. Running a stock Debian guarantees that at least one coworker can work with the servers, and others may find solutions through Google.

The trick to get the server to reboot even when systemd has wetted its pants is to sync, hope for the best, and run systemctl --force --force reboot. Almost as good as pressing the reset button while the HDD LED still blinks. Well, the fileserver seems to have survived. ext4 is pretty robust. And if something broke unnoticed, I have a good backup.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Replies are listed 'Best First'.
Re^2: How not to implement updaters
by hippo (Archbishop) on Nov 11, 2022 at 23:13 UTC
    Completely unrelated, systemd running as process 1 (a.k.a. init) on our fileserver decided to crash, complain loudly on the console how evil the world is, disconnected from /dev/initctl and dbus, and made the entire server refuse to reboot.

    I feel your pain. There have been some terrible, terrible IT decisions made over the last quarter century but IMHO systemd takes the absolute biscuit. On systems where I have any say in the matter we do not and never will run systemd because I, apparently unlike many others, prefer my systems to boot reliably. It should be no surprise to anyone that Poettering now works for M$ (and still tries to infect superior systems with his crud).


    🦛

        After reading the link you posted and the included https://github.com/systemd/systemd/issues/6237, which is a case-in-point where systemd runs unit's process as root if username starts with digit, some systemd uber-programmer (poetering whatever) makes the wild claim that such usernames are invalid and blames it on bugs elsewhere outside systemd:

        "0day" is not a valid username. I wonder which tool permitted you to c +reate it in the first place
        (https://github.com/systemd/systemd/issues/6237#issuecomment-311900864)

        this is what is wrong with systemd and similars (like NetworkManager IMO): the lethal combination of ignorance+audacity. Little god syndrome.