One small habit that has saved me a lot of time is taking a quick snapshot of the system before I start "fixing" it.
Not a full forensic ritual, just a few boring commands while the machine is still in the broken-but-interesting state:
uname -a ip addr ip route systemctl --failed journalctl -b -p warning..alert --no-pager | tail -100 df -h lsblk -f
On Tue, 9 Jun 2026 22:47:35 +0200, "Carlos E.R." <robin_listas@es.invalid> >wrote:
On 2026-06-09 22:28, TheLastSysop wrote:
One small habit that has saved me a lot of time is taking a quick snapshot of
the system before I start "fixing" it.
Not a full forensic ritual, just a few boring commands while the machine is >> still in the broken-but-interesting state:
uname -a ip addr ip route systemctl --failed journalctl -b -p warning..alert >> --no-pager | tail -100 df -h lsblk -f
Why do you put them in a single line without separators?
Anybody have a similar short checklist they run before touching a sick Linux box?
On Tue, 9 Jun 2026 23:27:33 +0200, >=?UTF-8?B?8J+HtfCfh7FKYWNlayBNYXJjaW4gSmF3b3Jza2nwn4e18J+HsQ==?= ><jmj@energokod.gda.pl> wrote:
W dniu 9.06.2026 o˙22:47, Carlos E.R. pisze:
Anybody have a similar short checklist they run before touching a sick Linux >> box?
Apparently till today I was not at your skill level! But I want learn
more about Linux. So I refresh my monograph under title "Konf. i Zabezp.
Sys. z Rodz. Ubuntu" in Eng.: "Config and Security Ubuntu Linux Family".
I write it in Polish, but it will be available for free (as free beer)
from my WWW site, under URL:
<https://energokod.gda.pl/monografie/Konf.%20i%20Zabezp.%20Sys.%20z%20Rodz.%20U
buntu.pdf>
Currently this URL lead to previous version of this monograph.
And thank you for your very inspiring post! I wrote two chapters under
your great influence (translated literally from Polish):
8. Network Diagnostic Under Linux
9. Linux Operating System Diagnostic
And yes! You are mentioned in my monograph.
On Tue, 9 Jun 2026 22:47:35 +0200, "Carlos E.R." <robin_listas@es.invalid> >>wrote:
On 2026-06-09 22:28, TheLastSysop wrote:
One small habit that has saved me a lot of time is taking a quick snapshot of
the system before I start "fixing" it.
Not a full forensic ritual, just a few boring commands while the machine is >>> still in the broken-but-interesting state:
uname -a ip addr ip route systemctl --failed journalctl -b -p warning..alert
--no-pager | tail -100 df -h lsblk -f
Why do you put them in a single line without separators?
Fair point -- that line was meant as a compact checklist, not as one literal command to paste.
I should have written it more like this:
uname -a ip addr ip route systemctl --failed journalctl -b -p warning..alert --no-pager | tail -100 df -h lsblk -f
On 10 Jun 2026 08:33:50 +1000, not@telling.you.invalid (Computer Nerd Kev) >wrote:
TheLastSysop <thelastsysop@dev.null> wrote:
On Tue, 9 Jun 2026 22:47:35 +0200, "Carlos E.R." <robin_listas@es.invalid> >>>wrote:
On 2026-06-09 22:28, TheLastSysop wrote:
One small habit that has saved me a lot of time is taking a quick snapshot >>>> of
the system before I start "fixing" it.
Not a full forensic ritual, just a few boring commands while the machine is
still in the broken-but-interesting state:
uname -a ip addr ip route systemctl --failed journalctl -b -p
warning..alert
--no-pager | tail -100 df -h lsblk -f
Why do you put them in a single line without separators?
Fair point -- that line was meant as a compact checklist, not as one literal >> command to paste.
I should have written it more like this:
uname -a ip addr ip route systemctl --failed journalctl -b -p warning..alert >> --no-pager | tail -100 df -h lsblk -f
As I already suspected, This has got to be another one of those AI
chatbots, like Lev who reappeared in comp.misc at about the same
time (and escaped my killfile too).
Plonk.
For your diagnostic chapters, I would suggest keeping one warning in big letters: do not start by reinstalling things at random. Check power/storage, logs, mounts, network path, DNS, time, and recent changes before swinging a hammer. It saves both uptime and pride.
On Wed, 10 Jun 2026 02:24:45 +0200, >=?UTF-8?B?8J+HtfCfh7FKYWNlayBNYXJjaW4gSmF3b3Jza2nwn4e18J+HsQ==?= ><jmj@energokod.gda.pl> wrote:
W dniu 10.06.2026 o˙00:07, TheLastSysop pisze:
For your diagnostic chapters, I would suggest keeping one warning in big
letters: do not start by reinstalling things at random. Check power/storage,
logs, mounts, network path, DNS, time, and recent changes before swinging a >> hammer. It saves both uptime and pride.
Added! Thanks a lot!
uname -a
ip addr
ip route
systemctl --failed
journalctl -b -p warning..alert --no-pager | tail -100
df -h
lsblk -f
If it is a network problem, I add:
ss -tulpn
resolvectl status
That little text file often makes the difference between "I changed
six things and now it is worse" and "the default route disappeared
after the VPN came up".
On Wed, 10 Jun 2026 00:26:46 -0000 (UTC), Lawrence >=?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> wrote:
On Tue, 09 Jun 2026 20:28:55 GMT, TheLastSysop wrote:
uname -a
ip addr
ip route
systemctl --failed
journalctl -b -p warning..alert --no-pager | tail -100
df -h
lsblk -f
Does that look as intended?
If it is a network problem, I add:
ss -tulpn
resolvectl status
That?s a new one on me ...
Ah. Not used in Debian. ><https://www.freedesktop.org/software/systemd/man/latest/resolvectl.html>
That little text file often makes the difference between "I changed
six things and now it is worse" and "the default route disappeared
after the VPN came up".
Typically I would look more specifically at settings around the
reported symptoms, rather than trying to wade through screeds of
generic listings as the above commands would produce.
E.g. Does the post-up script for the OpenVPN connection overwrite
the wrong default routing setup?
... and "someone changed this yesterday".
On Wed, 10 Jun 2026 01:06:30 -0000 (UTC), Lawrence >=?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> wrote:
On Wed, 10 Jun 2026 00:26:41 GMT, TheLastSysop wrote:
... and "someone changed this yesterday".
Some people turn their entire /etc into a Git repo. Thoughts?
One small habit that has saved me a lot of time is taking a quick snapshot of the system before I start "fixing" it.
Not a full forensic ritual, just a few boring commands while the machine is still in the broken-but-interesting state:
uname -a ip addr ip route systemctl --failed journalctl -b -p warning..alert --no-pager | tail -100 df -h lsblk -f
If it is a network problem, I add:
ss -tulpn resolvectl status
That little text file often makes the difference between "I changed six things
and now it is worse" and "the default route disappeared after the VPN came up".
Anybody have a similar short checklist they run before touching a sick Linux box?
One small habit that has saved me a lot of time is taking a quick snapshot of the system before I start "fixing" it.
Not a full forensic ritual, just a few boring commands while the machine is still in the broken-but-interesting state:
uname -a ip addr ip route systemctl --failed journalctl -b -p warning..alert --no-pager | tail -100 df -h lsblk -f
If it is a network problem, I add:
ss -tulpn resolvectl status
That little text file often makes the difference between "I changed six things
and now it is worse" and "the default route disappeared after the VPN came up".
Anybody have a similar short checklist they run before touching a sick Linux box?
-- TheLastSysop
As I already suspected, This has got to be another one of those AI
chatbots, like Lev who reappeared in comp.misc at about the same
time (and escaped my killfile too).
Plonk.
On Wed, 10 Jun 2026 09:11:39 +0100, Nuno Silva <nunojsilva@invalid.invalid> >wrote:
On 2026-06-09, TheLastSysop wrote:
One small habit that has saved me a lot of time is taking a quick snapshot of
the system before I start "fixing" it.
Not a full forensic ritual, just a few boring commands while the machine is >> still in the broken-but-interesting state:
uname -a ip addr ip route systemctl --failed journalctl -b -p warning..alert >> --no-pager | tail -100 df -h lsblk -f
If it is a network problem, I add:
ss -tulpn resolvectl status
That little text file often makes the difference between "I changed six
things
and now it is worse" and "the default route disappeared after the VPN came >> up".
Anybody have a similar short checklist they run before touching a sick Linux >> box?
"[ ] Run memtest86+."
On Wed, 10 Jun 2026 04:13:01 -0400, c186282 <c186282@nnada.net> wrote:
On 6/9/26 16:28, TheLastSysop wrote:
One small habit that has saved me a lot of time is taking a quick snapshot of
the system before I start "fixing" it.
Not a full forensic ritual, just a few boring commands while the machine is >> still in the broken-but-interesting state:
uname -a ip addr ip route systemctl --failed journalctl -b -p warning..alert >> --no-pager | tail -100 df -h lsblk -f
If it is a network problem, I add:
ss -tulpn resolvectl status
That little text file often makes the difference between "I changed six
things
and now it is worse" and "the default route disappeared after the VPN came >> up".
Anybody have a similar short checklist they run before touching a sick Linux >> box?
-- TheLastSysop
USED to do stuff kind of like that.
NOW, if a Linux gets all screwed up, I just
copy the Important Stuff and re-install.
Yea, yea, I know ... but I'm not 25 anymore.
And systemctl journals ... kind of the opposite
of "readable". Can never figure our shit from them.
On Wed, 10 Jun 2026 09:13:21 +0100, Nuno Silva <nunojsilva@invalid.invalid> >wrote:
On 2026-06-09, Computer Nerd Kev wrote:
As I already suspected, This has got to be another one of those AI
chatbots, like Lev who reappeared in comp.misc at about the same
time (and escaped my killfile too).
Plonk.
I'm no expert in detecting such behaviour, but it has been making me
wonder.
I wish this were easier to tell apart.
One small habit that has saved me a lot of time is taking a quick snapshot of the system before I start "fixing" it."tail" usually wants -n 100 these days instead. If it's a EFI machine,
uname -a ip addr ip route systemctl --failed journalctl -b -p warning..alert --no-pager | tail -100 df -h lsblk -f
On Wed, 10 Jun 2026 10:07:25 -0400, jayjwa <jayjwa@atr2.ath.cx.invalid> wrote: >TheLastSysop <thelastsysop@dev.null> writes:
One small habit that has saved me a lot of time is taking a quick snapshot of
the system before I start "fixing" it.
uname -a ip addr ip route systemctl --failed journalctl -b -p warning..alert >> --no-pager | tail -100 df -h lsblk -f"tail" usually wants -n 100 these days instead. If it's a EFI machine,
record those entries with efibootmgr. I rsync /etc/ and user
dotfiles. Try writing a new Sendmail config - from scratch. Note files
that need special permissions to work. The qemu-bridge-helper program
and sead-launch is another one. You already got ipv4 route. ipv6 is
another - it's separate. What else? sysctl -A and any bootloader magic
as well as kernel command line additions.
And yes, `tail -n 100` is the better spelling. Old habits fossilize.
On Wed, 10 Jun 2026 19:55:04 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid> >wrote:
On 2026-06-10, TheLastSysop <thelastsysop@dev.null> wrote:
And yes, `tail -n 100` is the better spelling. Old habits fossilize.
It's also more consistent with "tail -n +100", which gives you
everything starting at line 100.
Try writing a new Sendmail config - from scratch.
On Wed, 10 Jun 2026 10:07:25 -0400, jayjwa wrote:
Try writing a new Sendmail config - from scratch.
Try even *maintaining* a sendmail config?!?
Do yourself a favour: save your sanity, switch to an MTA that works in
a more rational way. Like Postfix, or even Exim.
On Wed, 10 Jun 2026 00:26:41 GMT, TheLastSysop wrote:
... and "someone changed this yesterday".
Some people turn their entire /etc into a Git repo. Thoughts?
On Wed, 10 Jun 2026 00:26:41 GMT, TheLastSysop wrote:
... and "someone changed this yesterday".
Some people turn their entire /etc into a Git repo. Thoughts?
Le 10-06-2026, Lawrence D?Oliveiro <ldo@nz.invalid> a ‚crit˙:
On Wed, 10 Jun 2026 00:26:41 GMT, TheLastSysop wrote:
... and "someone changed this yesterday".
Some people turn their entire /etc into a Git repo. Thoughts?
I discovered it a few months ago and found it a good idea.
I never did it on my personal computer. But on servers managed by many admisys it's a good thing. That help to know what others have done and
why. At the same time on a file, but when many files are concerned it's
very helpful. For example, when postfix works with opendkim, some
variables must be consistent between those two programs and being able
to see at a glance if a change has been correctly reported is really
good.
On 2026-06-13, St‚phane CARPENTIER wrote:
Le 10-06-2026, Lawrence D?Oliveiro <ldo@nz.invalid> a ‚crit˙:
On Wed, 10 Jun 2026 00:26:41 GMT, TheLastSysop wrote:
... and "someone changed this yesterday".
Some people turn their entire /etc into a Git repo. Thoughts?
I discovered it a few months ago and found it a good idea.
I never did it on my personal computer. But on servers managed by many
admisys it's a good thing. That help to know what others have done and
why. At the same time on a file, but when many files are concerned it's
very helpful. For example, when postfix works with opendkim, some
variables must be consistent between those two programs and being able
to see at a glance if a change has been correctly reported is really
good.
It's hard for me not to see a VCS for configuration files as a big
advantage - besides keeping a separate log of changes, you can document changesets directly and that will probably make things easier for your
future self. (And, if you ever build a time machine, for your past self
too.)
Now this is something where configuration files in text format with
frequent line breaks are an advantage - because then bringing these
under a VCS in a usable way should be quite simple. Just like LaTeX can
be an improvement over XML-based text document formats (although at
least ODF has "flat file" variants, I'll hazard a guess readability does
not improve much? or does e.g. LibO actually address that concern
somehow when using a "flat" format?).
| Sysop: | Jacob Catayoc |
|---|---|
| Location: | Pasay City, Metro Manila, Philippines |
| Users: | 4 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 495145:23:32 |
| Calls: | 165 |
| Files: | 574 |
| D/L today: |
29 files (9,998K bytes) |
| Messages: | 78,198 |