Tag: Command Line

Noted for future reference: Fixing a slow-to-boot Linux server

I have a few Ubuntu Linux VPSes that were originally spun up on the then-latest-and-greatest 16.04 LTS. Over the past year I’ve been belatedly upgrading them to 20.04 LTS. Almost without exception, all now have a really irritating flaw: where they used to reboot almost instantly — making me capriciously run OS updates involving reboots at any time of day, even on servers with a bunch of sites on them, since it only meant a blip of about 5 to 7 seconds — they were now consistently taking 2 to 5 minutes to reboot. Yikes!

Poking around, I learned that cloud-init was timing out, causing that delay, but since systems administration is just a small sliver of the work I do, I never had a chance to investigate why it was happening or really what cloud-init was even for. I just resigned myself to having to do those reboots in the middle of the night when no one would notice.

Well, I finally decided I needed to get an answer, and I found it. If I’m reading this correctly, cloud-init is really only needed during the initial creation of the VPS, and can safely be disabled after that. So, let’s do it!

touch /etc/cloud/cloud-init.disabled

I’m pleased to say, it works perfectly. I ran it on a test mirror of my biggest server and it worked, so I then applied it to the live server and… capriciously rebooted it, right in the middle of the day!

Shush. It worked.

Update (August 3, 2022): Mayyyyybe it’s a bit more complicated than what I described above. I just went into another server I had previously updated to 20.04, and I just went ahead and pre-emptively ran this before an update that required reboot. After the reboot, I could not connect to the server at all, other than through Digital Ocean’s direct access console. Thank goodness for that. It did not initially occur to me that this change might be why I couldn’t connect, but after trying a few other fixes without success, I just went in and deleted this new /etc/cloud/cloud-init.disabled file and rebooted, and everything came up just fine… and without any kind of delay on boot. Weird.

The uncomfortable marriage of the UNIX command line and Mac GUI, and its implications for my sudoers file

I’m a longtime Mac user. A “power user,” you might say. Not so much a power UNIX user, though I do a fair bit of Linux-based command line tomfoolery as part of my job.

But things get ugly when the two come together. At the command line I am a bit too inclined to treat my Mac like a Linux server. It may have UNIX at its core, but it’s not Linux. And Apple has put some effort into de-UNIX-ing it as well. Things you expect to work don’t work the way you expect them to. (Yes, I just wrote that sentence. See what this is doing to my brain???)

For reasons I don’t care to get into, I decided today that I needed to modify the sudoers file on the studio’s Mac mini file server. And in my own inimitable and slightly stupid way, I handled this task as I typically do anything involving changing buried system files, not by struggling through using a command line text editor, but by copying the file to my desktop (where it is magically released from the prison of UNIX file permissions in which Apple has… uh… imprisoned hidden UNIX system files). I edited the file and put it back in the /etc folder where it belongs.

Only problem: in the process, the file’s ownership and permissions got changed. No problem, I thought. I’ll just sudo that sucker. Only problem is, when the permissions on the sudoers file aren’t what the system expects them to be, it doesn’t let anybody sudo anything.

Well… crap.

But then I remembered… Mac GUI solutions to the rescue! I opened up Disk Utility and ran “Repair Disk Permissions.” Problem solved! Apple has saved me from myself.

Now I can go back to my delusion that I am a power user.

Removing the Leopard Dock’s “shininess”

I know there were already dozens of blog entries the day after Leopard “dropped” with instructions on how to remove the shiny Dock, but I’ve actually been living with it peacefully and almost liking it.

But now at my new job, I’m not sure if it’s the saturated color on my iMac display, the particular desktop image I’m using, or some strange combination of those and other factors, but the Dock’s reflection was painfully (yes, painfully) shiny and distracting, so I just had to look up how to get rid of it.

Apparently there’s a whole cottage industry now around customizing the Leopard Dock’s appearance, but all I really wanted was the simple look you get when you have the Dock on the left or right side, but when the Dock is resting nicely on the bottom where it belongs. It was surprisingly difficult (in that I had to do three whole searches and then hunt through a few links on the first page of results of each) before I found (again) the simple command line instructions to accomplish this task. And in the interest of saving myself the trouble next time (if there is a next time), I’m posting them here:

defaults write com.apple.dock no-glass -boolean YES
killall Dock