Bryant's questions

I know the release was delayed until Aug 29th, but its now September and I still cannot upgrade to 24.04. This is Ubuntu Server.

$ sudo do-release-upgrade -c
Checking for a new Ubuntu release
There is no development version of an LTS available.
To upgrade to the latest non-LTS development release
set Prompt=normal in /etc/update-manager/release-upgrades.

This is post apt update / upgrade. Even did a reboot afterwards and tried again for good measure. Was the server LTS point release delayed (not sure if its a separate release train from the Desktop release)?

My server unexpectedly powered down today. From syslog, it seems like it might have been the unattended upgrade service:

Nov 22 15:23:25 lynx systemd[1]: unattended-upgrades.service: Succeeded.
Nov 22 15:23:25 lynx systemd[1]: Removed slice system-modprobe.slice.
Nov 22 15:23:25 lynx systemd[1]: Stopped target Graphical Interface.
Nov 22 15:23:25 lynx systemd[1]: Stopped target Multi-User System.
Nov 22 15:23:25 lynx systemd[1]: Stopped target Login Prompts.
Nov 22 15:23:25 lynx systemd[1]: Stopped target Host and Network Name Lookups.
Nov 22 15:23:25 lynx systemd[1]: Stopped target Timers.
...
etc

The omitted parts are a list of various services that systemd is shutting down. If I look at the output of last:

$ last -x | head | tac
...
shutdown system down  5.4.0-90-generic Mon Nov 22 15:23 - 17:14  (01:51)
reboot   system boot  5.4.0-90-generic Mon Nov 22 17:14   still running
runlevel (to lvl 5)   5.4.0-90-generic Mon Nov 22 17:15   still running

I can see that the shutdown was properly logged to the system, and then you can see 2 hours later when I noticed the machine was down and rebooted it. My question is two fold - Why did this happen, and how do I configure this? I've been running this machine for years and I don't think I can recall it ever shutting down for an update before. The logs make me think it was unattended upgrade that did this, but I'm not sure how to verify that. If I understood how to configure unattended upgrade's settings/options I might notice something that controls it rebooting or shutting down, which is why I want to know how to do that. I'd prefer to either disable this (no shutdown) or change it to reboot (if the machine is on, I want it to stay on!). Any suggestions?

On two different servers I have redis and postgresdb installed. Neither will start successfully on boot, but will start if they are manually started/restarted. The error for both are the same (failure to bind to address). Here is an example of the postgres log:

2021-05-27 21:12:39.703 UTC [682] LOG:  starting PostgreSQL 12.6 (Ubuntu 12.6-0ubuntu0.20.04.1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, 64-bit
2021-05-27 21:12:39.704 UTC [682] LOG:  listening on IPv4 address "127.0.0.1", port 5432
2021-05-27 21:12:39.707 UTC [682] LOG:  could not bind IPv4 address "192.168.86.222": Cannot assign requested address
2021-05-27 21:12:39.707 UTC [682] HINT:  Is another postmaster already running on port 5432? If not, wait a few seconds and retry.

and redis:

653:M 27 May 2021 21:12:23.090 # Could not create server TCP listening socket 192.168.86.234:6379: bind: Cannot assign requested address

the machines are running on separate hardware, but both running the same version of ubuntu (20.04.2 LTS). Those IP addresses are static for those machines, so nothing else is using them, and the fact I can find to them immediately after boot (when I restart the services) leads me to believe its not a case of the address actually being in use elsewhere. I'm not quite sure what the cause of the issue is. My best guess is that the services are trying to start before the networking service is completely up/configured, but I'm not sure how to verify or confirm this. Any ideas or suggestions?

My Linux desktop is 4 years old. I originally named it "foo", but 2ish years ago renamed it "bar". I turned on backups for the first time today using Deja Dup, and it used the old computer/hostname from 4 years ago, "foo", as opposed to the current name "bar". I cannot figure out where the old hostname is coming from. I've verified the name is correct in the following locations:

• /etc/hosts
• /etc/hostname
• hostname
• hostnamectl
• Settings > About > Device Name
• python -c 'import socket; print socket.getfqdn()'
• uname -n

I'm at a loss. I'm not sure where the old hostname would still be stored, and how Deja Dup is attempting to discern the computer name for the backup path. Any ideas?!

I installed a fresh install of 18.04 server. The package redis-server does not seem to be installable. I'm not sure why:

$ sudo apt install redis-server
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Unable to locate package redis-server

the package doesnt appear to exist:

$ sudo apt-cache search redis
miscfiles - Dictionaries and other interesting files
python-redis - Persistent key-value database with network interface (Python library)
resource-agents - Cluster Resource Agents

I have run apt update. I'm guessing its missing a repository of packages, but since this is a fresh install, I'm not sure why it would be missing one, or how to fix it.

root@:/etc/newrelic# sudo apt-get install nri-redis 
Reading package lists... Done 
Building dependency tree 
Reading state information... Done 
E: Unable to locate package nri-redis

I have a hard drive mounted as /data. I'm the owner of the mountpoint, and I own all the directories under it. I installed an IDE under /data. It contains a shell script you need to execute to setup the IDE. This file is also owned by me, and is user, group, world executable. (i.e. I don't need chmod +x ...). For some reason, it wont let me execute the script. I continually get permission denied errors. As soon as I move the file to my home directory, with no permissions changes, it lets me execute the script. Is there a setting somewhere that is preventing me from executing files outside of my home directory, even if I own them and they are set as executable?

In case it matters, I'm running 16.04.