15:34:39 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. 17:45:36 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 17:45:41 ? 17:53:08 bsdbandit: is xrandr seeing the external connection? 18:16:46 Whoever mentioned "sudo shutdown -r now; exit" to save shell history, now I get it. ahh, it was xtile, not here right now. 18:37:32 dvl: how's that work? huh? 18:38:04 meena: shutdown -r now doesn't save your browser history, apparently. 18:38:14 * shell, not browser. 18:38:37 why does ; exit work, tho? 18:40:02 meena: I'm guessing that when the shell exits,it does a save. 18:41:45 hrm, shutdown would send a SIGTERM, is that not the kind of exit a shell likes? 18:42:34 * meena has been using Fish for ten years now 18:50:35 [Feb 11 04:59] If you do it as "shutdown -r now ; exit" you can save your tcsh history ;) 18:52:12 I wonder what other shells do 18:54:51 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. 18:57:03 last import two years ago? https://github.com/freebsd/freebsd-src/tree/main/contrib/tcsh 18:57:04 Title: freebsd-src/contrib/tcsh at main · freebsd/freebsd-src · GitHub 18:57:25 Looks like zsh does the history save, but it might do it on every command entered. 18:58:17 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. 18:58:45 Full disclosure: I am just reading the docs right now and have not tried it yet. 18:59:01 https://github.com/tcsh-org/tcsh/search?q=SIGTERM&type= 18:59:02 Title: Search · SIGTERM · GitHub 19:01:30 My initial testing, never a user of tcsh, indicates it doesn't work. 19:02:05 Those search hits show that SIGTERM is trapped but more searching is needed to see what happens when it gets one. 19:02:05 I don't know what it's got to do with tcsh. 19:02:26 But one can just test it easily enough with "kill -15 $$" and see that the shells all ignore it by default. 19:02:30 "shutdown -r now ; exit" isn't a techism. 19:02:33 tcshism* 19:13:47 I assume tcsh is the shell dvl uses 19:14:01 pstef: It is not. 19:14:22 Cue what Samuel Clement didn't say. 19:15:00 well, I got easily fooled by the part where xtile says "save your tcsh history" 19:21:27 pstef: I was a longtime bash user, and relatively recently moved to zsh 19:23:21 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 19:23:54 what about SIGWINCH 19:28:32 For the record, with csh/tcsh you can also do: history -M && shutdown -r now 19:28:46 SIGFLINCH and you'll lose 19:32:04 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. 19:32:51 Merges and sorts by timestamp, according to the manual page; interesting, I'd forgotten about the timestamp merge. 19:34:26 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. 19:34:30 over* 19:35:12 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. 19:35:19 s/commands/actions/ 19:35:26 That's part of why top -q exists. 19:35:41 Wait, wrong window. 19:37:11 Can anyone guess the context? 19:38:12 In the meantime, I'll also note that I think I understand why dvl has run into the issue. 19:39:40 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. 19:41:53 200 years, when Unix systems had users that weren't just daemons 19:43:54 Or use "shutdown -h +5min && sleep 240 && shutdown -k" which comes to the same. 19:45:18 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. 19:45:38 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? :) 19:45:49 spork_css: Yes, I am. 19:46:13 Can confirm, dvls reach is far and fearsome. 19:48:14 dvl: heck, you could even do "shutdown -r +5s" then simply log out manually, which should save your history. 19:48:48 At least until someone finds a way to trap SIGTERM long enough for the history to be saved, I guess? 21:39:14 This was the fix for my IPv6 alias issues: https://forums.freebsd.org/threads/trouble-with-ipv6-aliases.88008/#post-598310 21:39:15 Title: Solved - trouble with IPv6 aliases | The FreeBSD Forums 21:41:22 dvl: i'd say that ipv6 aliases should be /128, no? 21:42:35 otis: If that's the case, the examples are wrong: 21:42:36 % grep alias /etc/defaults/rc.conf | grep inet6 21:42:12 21:42:36 #ifconfig_em0_alias0="inet6 2001:db8:2::1 prefixlen 64" # Sample IPv6 alias 21:44:12 well, the "first" address from a subnet has "valid" prefix length, the subsequent aliases are /128 21:51:01 now trying /128 instead of ' prefixlen 64' on my IPv6 aliases. 22:08:38 For my next fun, vm does not start on reboot: https://forums.freebsd.org/threads/vm-bhyve-vm-does-not-start-on-reboot.88022/ 22:08:39 Title: bhyve - vm-bhyve vm does not start on reboot | The FreeBSD Forums 22:09:40 otis: the /128 works fine as well, from what I can tell. 22:21:46 dvl have you set vm_list? You need to do that 22:23:18 ceri: no, I was looking in the rc.d script and saw no reference to that. I see it now in man vm. 22:23:51 the startall function is misleadingly named 22:26:50 ceri: thank you, now I wait for the new OS vuln update. ;) 22:27:34 dvl: de nada