00:29:35 burie - can you create a 2nd virtual hard drive for output and then point /usr/obj at it? just a thought [then you can compress and save it when done]. Just temp add to fstab after setting it up for your VM so it loads on boot. 00:30:24 (format UFS simplest) 00:32:05 I sometimes do this kind of thing on embedded devices like RPi if I do not use a cross-compile, allows me to use NFS even for the output files or an external USB drive 02:17:45 gents, i have a fresh install of bsd that im configuring, and after putting up pf, i see i have 3 persistent connections to ips in amazon's cloud. its driving me up a wall trying to figure out what is talking; any ideas 02:17:55 is it pkgtool? 03:34:55 I'm a noob, but doesn't lsof do that? 03:40:05 sure. sockstat should as well 03:53:31 Ah, cool. Clearly, if neither lsof or sockstat report anything, then you have an NSA backdoor. :) 04:07:52 thats exactly it 05:27:20 shbrngdo: it's opinion that rpi should be categorized different from embedded system unless you touch baremetal. you may miscommunite with others. 06:44:10 rwp you were right about the unable to setup mem prob not being zfs arc. i needed to destroy the vm then i could start it fine 07:38:47 bhyvectl --destroy 10:40:16 considering adding a 3rd vdev to my main zpool mirror, on a large box downstairs, via iscsi, as a temporary backup. 10:40:39 its 1GiB network only so copying ~ 1.5TiB will take a while 11:20:47 is that like your version of the meme "feeling cute might expand my zpool"? 11:44:56 heh. no, its a prudent move (3-way mirror) while I upgrade the firmware on the 2 nvme in the zpool 13:31:03 luke_jobless_sb - good point, though I always seem to be using them for embedded systems, touch screen controllers basically. working on one todY ctually 13:53:02 Does anybody run Syncthing? 13:54:40 I do, though not on FreeBSD 13:55:14 s2r: i do, on many platforms 13:55:52 drijen: did you figure out what your rogue connections were? 14:04:38 rtprio: me too, I wanted to know if you had any issues with cpu consumption. 14:06:11 rtprio: I've got it in a jail and it consumes almost the same as a vm running linux+mssql. I read about kqueue but I wanted to know if anybody was able to fine tune it. 14:06:37 i don't notice anything; it has several of minutes of cpu time over the past two months, my system's not pegged or anything 14:07:04 s2r: i think it can also depend on your workload, if it's watching, say, your mp3 library continously, rather than every 12 hours 14:09:46 rtprio: I sync "My Documents" from different laptops, my thunderbird archived emails and also my photos folder however I paused the last one. I will try changing the frequence. 14:10:26 frequency, sorry 14:20:09 PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 14:20:09 90783 elliot 1 68 0 32M 22M select 6 227:13 0.39% tmux 14:20:10 74952 elliot 159 34 9 1586M 172M uwait 5 137:59 0.00% syncthing 14:20:20 I do not know if that's a lot or a little cpu time 14:41:23 PID JID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 14:41:23 34035 3 983 15 97 9 1525M 215M uwait 2 71.3H 0.01% syncthing 14:41:51 rtprio: uptime 52 days. 16:07:00 huh is `ctl(1)` single threaded? 16:44:20 if anyone uses databases/prometheus-postgres-exporter, please feel free to test this patch to update to 0.16.0: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282695 16:44:40 (i feel that i may be the only person in the world who uses freebsd and postgres and prometheus, but who knows!) 17:14:34 ivy: so do I! although this week is pretty hectic for me, I'll try after wednesday :) 17:17:47 is there a program or script that can run some commands, and if any of them fails, to e-mail me the output ? 17:18:45 last1: Sure. You can do that in a script quite easily. 17:20:05 last1: is this is for cron, i usually use a wrapper script that runs the command and emails the output to root on failure, which is fairly easy to write 17:20:16 then just use 'set -e' in your actual scripts so they abort on failure 17:21:44 Hecate: if you test it and it works, please leave a comment on the bug with your freebsd version/arch as this helps committers see that the patch works 17:22:02 well, it is for cron, but I want it to run like 5-6 commands, one after another, so I'd rather put it in a shell script 17:22:06 vs 5-6 cron entries 17:22:13 i don't mean you have 5-6 cron entries 17:22:24 i mean you have one cron entry which is like '/usr/local/bin/cronjob /usr/local/bin/my-actual-script' 17:22:30 Write a script. Have the script save up output and email upon an error. Call the script from cron. 17:22:40 my-actual-script uses set -e, and cronjob just runs it and emails the output to root if it exits <> 0 17:22:49 yes, but that script runs itself 5-6 commands, so so it's irrelevant on whether the script itself fails or succeeds 17:22:58 (I guess) 17:23:06 I care about the status of each internal command 17:23:12 set -e causes the script itself to fail if the commands it runs fail 17:23:29 As a counter point, I am in the camp that does not like set -e because it doesn't do what people think it does. 17:25:02 Let's see, this for example: http://mywiki.wooledge.org/BashFAQ/105 17:28:46 Don't let that it is a bash faq fool you. I always use /bin/sh for scripts and the same applies. 17:30:01 For the symbolic names in /dev/ufs and /dev/diskid, how do I find out why /dev/ada or /dev/da device they map to? It was geom-something. 17:31:20 ?? geom -t ?? 17:32:07 Thank you! 17:32:09 I am mostly using zfs not ufs, I am using gpt labels not glabel labels, but I am hoping that still produces the info. 17:32:19 may be overkill but I asked chatgpt to write me a perl script that runs commands and e-mails me in case of failure 17:33:08 If something is worth doing then it is worth doing to excess. 17:34:06 I have a strategy where with anything I run by cron I use a semaphore so that on a busy system a command that doesn't finish before the next one starts won't make the system load climb endlessly trying to start more cronjobs. 17:34:37 I then create a temporary file and redirect all output to the temporary file. But using a temporary file requires signal handles to cleanup when interrupted. 17:34:54 Then if the task has an error I mail the contents of the temporary file. 17:42:03 This is a template of what I do. https://paste.debian.net/plain/1335215 17:42:22 last1: why would you use perl for that, it's like 5 lines of shell script 17:45:15 I think the shell is better for it too. The basic being: if ! somecommand; then echo failed | mailx -s error $(whoami); fi 17:45:44 seemed easy, but then I wanted to use a remote smtp server 17:46:21 Configure dma to use the remote server. And then everything from then forward that sends email on the system works. 17:46:58 (I am a postfix fan but dma is in fashion these days.) 17:47:25 rwp: I use semaphores too, in fact, since I love Perl, I use a module to ensure a script only runs if no other instances exist 17:47:33 but I find that even so, somehow, semaphores get stuck 17:47:37 I need to use ipcrm to get rid of them 17:58:08 Stale semaphores are a problem! (shrug) It probably means that the program is exiting by some route that is not cleaning up the semaphore. 17:58:44 In perl if fcntl() locks are used then the kernel will guarantee that cleanup when the creating process exits. That should resolve the problem. 18:00:15 In shell, what I am using, there is no easy way to do that. So I drop a semaphore-dir in /tmp and my systems clean /tmp on boot. I almost never see problems but sometimes a system will hit the ground and start digging and I will reboot the system and that guarantees that everything will have a clean start after a reboot. 18:00:32 rwp: do you often create semaphores in shell scripts? 18:00:44 i'm not sure i ever had a use case for that 18:01:26 ivy, Only in cron scripts. It's only in cron scripts where there is a danger of the cron not finishing before the next cron starts a new one. In that case the semaphore prevents repeating cron tasks from continuously stacking up new processes and making the problem worse. 18:02:15 Something that runs once a day is almost never going to be a problem. But something that needs to run, say, every five minutes, definitely runs into a danger of having processes create too many more processes and overpopulate the system. 18:02:55 That can happen for network file systems that get wedged. That can happen with bare metal local file systems that are suffering some failure. And for other reasons. 18:04:18 Sometimes I am running a find and delete cleaner on what starts out as a small directory of files used for something and then over time the directory grows to ten godzillian files and it takes a long time to run, perhaps too long, especially if something else has pushed out the read cache causing things to run even slower. Just as an example of how bad things can happen. 18:05:02 rwp: I do the same thing. Especially for backups and cleanups, like you're mentioning. 18:05:06 I am also working with other people and not writing everything myself. I like to have a little safety net built into other people's code. 18:06:03 Backup! My desktop one time started to take more than 24 hours to complete the backup. It was always eventually successful. No errors. But then I noticed that things were slow and saw I had overlapping backups running! 18:06:22 yeah, exactly, semaphores are good for that 18:06:23 rwp: Exactly! 18:07:23 And, I too dump to tmpfile and email the contents of said tmpfile if anything exists with non-zero (usually.) 18:07:44 It's a time honored strategy! :-) 18:08:23 Yep. It simply works and I don't need to put a lot of time or energy into it. Set it and forget it. 19:25:40 rwp, do you know that in bourne shell scripts you can trap on EXIT, same way as a signal handler? I use that for cleanup. 19:32:50 cracauer, I do. And I do use that. That's so my cleanup handler is always exercised even in the normal script exit. 19:34:12 If you are Martin though then I know you know that different shells handle that differently. For example in bash the EXIT trap is triggered upon interrupt too. But dash does not so those signals must be associated explicitly. 19:34:54 Ah. Good to know. 19:35:44 I see your nick and I am thinking: https://www.cons.org/cracauer/sigint.html 19:36:12 Yeah, that's me. 19:36:37 Respect! :-) 19:37:11 I figured you saw my paste earlier and were commenting upon it. https://paste.debian.net/plain/1335215 19:37:41 Didn't see that, no. 19:40:18 One of the problems that often happens is that people write code that needs an at-exit type of cleanup. And they call it at exit time. 19:40:22 But that also needs to happen upon signal handling exit time too. 19:40:25 But a lot of people then do that again in the signal handler. That violates the DRY principle Don't Repeat Yourself. 19:40:31 I feel that the cleanup should always be called the same way for both of those cases so that it is always exercised.