rtprio SarahMalik : so yesterday, i revert sysctl configs, and to not trigger the syncthing bug, I removed a lot of useless synced files

for now it works

my guess is RAM problem

when I configure kern.maxfiles and kern.maxfilesperproc, something bugs : this is not syncthing that is crashing the VM. If thoses are set to a higher value AND syncthing jail is stopped, it crashes

is that possible that it is a lack of RAM, even if the RAM usage remains at 50% in htop/netdata ?

fun fact : man.freebsd.org/cgi/man.cgi?query=k…ion=2&manpath=freebsd-release-ports

The Guy in See Also is named "Jonathan Lemon" which is my first name: Jonathan, and the first name of my dog: Lemon

rwp: im not running them as root though, the keepenv directive just seems to retain the env of the user executing doas

it's still living

great

I'm pretty sure if I add interfaces to a bridge the "real" interface goes down, then up, in the process

takes out the network for about 2 seconds

well, epairs don't seem to do it, but taps do

it goes igc0 down, tap0 up, igc0 up… and then in the other direction tap0 down, igc0 down, igc0 up

actually tap0 coming up is to do with vm-bhyve, if I manually make a tap interface then /var/log/messages just shows igc0 cycling

i haven't noticd my bridge down when i add taps

eoli3n: what sysctl did you revert?

rtprio: kern.maxfiles=100000 and kern.maxfilesperproc=32768

whois aut0m0rph

who indeed

I wonder if I've got some hardware option switched on that needs switching off

seti, Huh? You are using doas. So unless you are switching sideways to a different non-root account then you are running them as root. That's the purpose of doas. And just about the main purpose of keepenv is to preserve DISPLAY and possibly XAUTHORITY to run X programs.

rwp, re: keepenv also helps with other things. I have a local script to run the (real) vi editor at ~/bin/e , which in turn sources my EXRC and other ex scripts. Without keepenv, doas e <file> fails...

Updating my main host at home. FreeBSD 14.3 -> 15.0

Good luck!

Thank you. kernel installed, reboot time.

so far, so good: FreeBSD r730-01.int.unixathome.org 15.0-RELEASE-p2 FreeBSD 15.0-RELEASE-p2 GENERIC amd64

Wrong url entirely.

ant-x, We will need to wait and see what seti says they were actually doing.

What I do is that I set up root's files so that they are suitable and as I like them to be. Then I use sudo -i to run a login shell setting up the root environment. This works great on my own machines. On shared machines things need to be a little more clever using SUDO_USER and such.

rwp, in other words, you use root sessions directly, right?

If you have sudo set up then try "sudo -i env" and "sudo -i vi .profile" and it will source the root environment and work from there.

Is that a root session used directly?

I have not.

Then you will have to work off my report that sudo -i loads up the root environment and therefore "works" better. And sudo sets up a pty pair so that avoids complaints from tools that care about the security of such things too.

If you end up in # shell, then it means using a root session directly.

The root environment as defined for the root user, in / ?

Well... If you "sudo -i vi .profile" and then run :sh then you will end up with a shell.

I see. And vi in run with what environment -- yours or root's?

Root's environment.

Root's environment which has been configured to be safe for root. Unlike my own environment which perhaps is not safe for root. Unsafe PATH. Programs in PATH that are not really root safe.

OK, thanks.

I think doas runs in root's environment by default.

Not completely. doas does not change the current directory. doas does not change the tty device, which is still owned by the current user, which introduces security concerns.

Try: doas ls -ld $(tty)

Indeed.

For completeness "doas tty" which verifies that as the tty in the doas environment.

I knew it did not change the workdir, but considered it normal.

test $(doas tty) = $(tty) && echo yes

$ yes

I don't really see the advantage of doas yet but everyone talks about it so I configured it and started to use it so that I could know the details of it.

rwp, nor do I, except that it is more BSD-ish...

The hyped homebrew installer fails or behaves inadequately on a system without sudo.

ant-x, sudo was developed on 4.1BSD! What could be more BSD than that?

Something not present in Linux. doas was ported to Linux from BSD.

As was sudo which was also ported to linux from BSD. Via Solaris, HP-UX, and other traditional Unix systems.

I didn't know that at all.

I first encountered sudo on HP-UX sometime in the late 1980s ported from CU-Boulder sources.

Maybe it was the 1990s. Those years all blur together after a while.

Predates Linux being available regardless.