spork_css: Nothing new. I've managed to fix it, but I don't know why. I've saved some files from a snapshot so if I ever get the motivation to do so, I can investigate further to see if I can reproduce the error.

good afternoon im running freebsd on a lenvo x1 extreme laptop and im trying to get it to connect to a larger monitor using hdmi when connecting to the monitor for hdmi im not getting any output to the screen is there a command that im mising or is this just not supported out thge box

?

bsdbandit: is xrandr seeing the external connection?

Whoever mentioned "sudo shutdown -r now; exit" to save shell history, now I get it. ahh, it was xtile, not here right now.

dvl: how's that work? huh?

meena: shutdown -r now doesn't save your browser history, apparently.

* shell, not browser.

why does ; exit work, tho?

meena: I'm guessing that when the shell exits,it does a save.

hrm, shutdown would send a SIGTERM, is that not the kind of exit a shell likes?

[Feb 11 04:59] <xtile> If you do it as "shutdown -r now ; exit" you can save your tcsh history ;)

I wonder what other shells do

One would need to look at the tcsh source to see what happens on SIGTERM. Likely SIGTERM is ignored waiting for SIGHUP for the interactive shell.

last import two years ago? github.com/freebsd/freebsd-src/tree/main/contrib/tcsh

Title: freebsd-src/contrib/tcsh at main · freebsd/freebsd-src · GitHub

Looks like zsh does the history save, but it might do it on every command entered.

I think perhaps it might be less race condition prone in tcsh to do "history -S ; shutdown -r now" though. Just get the history saving done right up front.

Full disclosure: I am just reading the docs right now and have not tried it yet.

Title: Search · SIGTERM · GitHub

My initial testing, never a user of tcsh, indicates it doesn't work.

Those search hits show that SIGTERM is trapped but more searching is needed to see what happens when it gets one.

I don't know what it's got to do with tcsh.

But one can just test it easily enough with "kill -15 $$" and see that the shells all ignore it by default.

"shutdown -r now ; exit" isn't a techism.

tcshism*

I assume tcsh is the shell dvl uses

pstef: It is not.

Cue what Samuel Clement didn't say.

well, I got easily fooled by the part where xtile says "save your tcsh history"

pstef: I was a longtime bash user, and relatively recently moved to zsh

in any case, it seems it's up to the shell program to decide whether to save command history on SIGTERM or not, but maybe handling SIGTERM would open a can of worms I'm not aware of

what about SIGWINCH

For the record, with csh/tcsh you can also do: history -M && shutdown -r now

SIGFLINCH and you'll lose

I forget the exact wording from tcsh(1), but history is a builtin and -M merges the existing history into .history, similar to the "set savehist = (N merge)" directive that's part of the (t)csh skeleton file.

Merges and sorts by timestamp, according to the manual page; interesting, I'd forgotten about the timestamp merge.

It's specifically designed around the notion of doing things around a certain time, but avoiding executing everything at exactly the same time as this could (in theory) cause a server to fall oevr.

over*

I can't recall seeing FreeBSD fall over from too high a CPU load; at worst, it becomes unresponsive to interactive commands and slow at responding to all queries.

s/commands/actions/

That's part of why top -q exists.

Wait, wrong window.

Can anyone guess the context?

In the meantime, I'll also note that I think I understand why dvl has run into the issue.

Normally on a server with people interacting on the shell, the operator would issue a wall(1) before issuing the shutdown -k and then issue the actual shutdown command on the console.

200 years, when Unix systems had users that weren't just daemons

Or use "shutdown -h +5min && sleep 240 && shutdown -k" which comes to the same.

Hm. A former coworker of mine had a patch for shutdown that'd even let you set a time for -k - I wonder what happened to that.

dvl: had a 12.x host that's been up for a long time reboot and none of the v6 aliases came back, are you jinxing me over here? :)

spork_css: Yes, I am.

Can confirm, dvls reach is far and fearsome.

dvl: heck, you could even do "shutdown -r +5s" then simply log out manually, which should save your history.

At least until someone finds a way to trap SIGTERM long enough for the history to be saved, I guess?

This was the fix for my IPv6 alias issues: forums.freebsd.org/threads/trouble-…ith-ipv6-aliases.88008/#post-598310

Title: Solved - trouble with IPv6 aliases | The FreeBSD Forums

dvl: i'd say that ipv6 aliases should be /128, no?

otis: If that's the case, the examples are wrong:

% grep alias /etc/defaults/rc.conf | grep inet6 21:42:12

#ifconfig_em0_alias0="inet6 2001:db8:2::1 prefixlen 64" # Sample IPv6 alias

well, the "first" address from a subnet has "valid" prefix length, the subsequent aliases are /128

now trying /128 instead of ' prefixlen 64' on my IPv6 aliases.

For my next fun, vm does not start on reboot: forums.freebsd.org/threads/vm-bhyve-vm-does-not-start-on-reboot.88022

Title: bhyve - vm-bhyve vm does not start on reboot | The FreeBSD Forums

otis: the /128 works fine as well, from what I can tell.

dvl have you set vm_list? You need to do that

ceri: no, I was looking in the rc.d script and saw no reference to that. I see it now in man vm.

the startall function is misleadingly named

ceri: thank you, now I wait for the new OS vuln update. ;)

dvl: de nada