serious question: how high can keycodes go?

i suppose only 127?

AmyMalik, per keyboard(4), yes. Specifically, "The number of the key is transmitted as an 8 bit char with bit 7 as 0 when a key is pressed, and the number with bit 7 as 1 when released."

karolyi: Understandable! FWIW I've been running it since November, zero issues.

is there a OOM killer similar to Linux, on Linux you can do alt + prntscrn + f to invoke OOM killer to kill the biggest process

this can be used to kill screenlocks to unlock a device, something being discussed here at FOSDEM

but the exploit doesnt seem possible on FreeBSD :)

on Linux you need to ensure you set the priority to 0 to stop OOMkiller killing the process full stop

or disable OOM killer

polarian: are you sure it's printscreen and not sysrq? Anyway FreeBSD doesn't adhere to such an "over-commit model" like Linux does, and on Linux you need something lower than 0 (-5000 or something) for oom_score_adj or am I mistaken here?

:)

:)

Barnerd: that sounds promising. here's to hoping that others won't find any problems on their NICs and I can safely change over to it.

Hello, all. I am planning to upgrade my FreeBSD to v.15. Last time I upgraded it to 14.3, my modifications to etc files were overwritten. How can I avoid it this time?

^ For example, the upgrade revertd my global xinitrc .

when running `top`, the SWAP column always shows 0B for everything

even though the server is using 1 GB of swap

ant-x, To know this we would need to know what process was followed to do the upgrade. For example was this a new pkgbase upgrade? Was this a freebsd-update upgrade? Let's start there.

It was the freebase-update process for packages, as described in the Handbook.

rwp, at the end, I had to do `pkg upgrade -f', because some dependencies remained broken. Perhaps, this command rewrote my etc files?

That's strange then. I haven't done any upgrades to 15 yet but 12 to 13, 13 to 14, all preserved my changes in /etc okay.

"pkg upgrade -f" is a standard pkg upgrade after doing a major base upgrade. Sometimes even requiring pkg-static in order to run. Before pkgbase none of those would touch /etc because pkgs go into /usr/local so the only files modified were in /usr/local and the bookkeeping in /var/db/pkg/

Before pkgbase we really had to separate and independent systems. One was freebsd-update which handled the base system. pkg handled the /usr/local binary compiled ports tree. The two did not overlap.

Now with pkgbase I haven't used it yet and so can't talk from experience. But now that's no longer true. And I don't know anything about pkgbase yet.

Nor to I. I will be upgrading 14->15 the old way.

Now perhaps I'll try to do a minor upgrade within v. 14 on another machine is see when/how the etc files will be overwitten (or perhaps they won't).

The old way, and what you used for 14.3R, would have been freebsd-update and it would have used etcupdate as the lower level tool to merge changes into /etc.

Mabe at at a lower level, because I did not see it with my eye, nor was prompted about any mering.

* merging.

That's always worked for me. Therefore I haven't needed to really know how it works at the "need to debug" level.

Perhaps, Xinitrc is special? Do you use a custom Xinitrc?

My custom file is in ~/.xinitrc

well, for config files there is stuff to ensure that changes persist, but normal files (like /usr/local/etc/X11/xinit/xinitrc) will be fixed to be the way they should be when reinstalled or upgraded by pkg

Since /usr/local/etc/X11/xinit/xinitrc is in /usr/local we know it is handled by pkg (or ports) and freebsd-update won't touch it or know about it.

Ah, mine was global: for me and father.

And /etc/whatever will be handled by freebsd-update and pkg won't know about it.

OK. Will `pkg upgrade -f' rewrite it without any merging?

well, there is no xinitrc in /etc, so I assumed "the upgrade revertd my global xinitrc" meant /usr/local/etc/X11/xinit/xinitrc

Yes.

That's the global one (that is, not user-specific).

I thought that meant that you had created your own file in /etc. No? Well that detail changes things.

I am sorry for being unclear. I meant /usr/local/etc/X11/xinit/xinitrc .

yes, as it isn't a config file, pkg will override it

Hmmm. Then I have to know before hand which files to backup before pkg upgrade?

And what files not to modify. That file is not meant to be modified.

rwp, look at that file: it is surelu meant to be modified (by Xorg, at least). It start a clock and several Xterm instances -- a very specific decision for the user!

What project/architect thinks xinitrc is not meant to be modified?

Me! For one. I am going to spend a few moments reading the documentation...

Thanks.

startx(1) just says it is the system-wide xinitrc , used if there is no ~/.xinitrc for the user.

It also says "Sites that want to create a common startup environment could simply create a default .xinitrc that references a site-wide startup file: "#!/bin/sh\n. /usr/local/etc/X11/xinit/site.xinitrc"

And also "Another approach is to write a script that starts xinit with a specific shell script. ..."

That's in the xinit page, yes. Or I could do it via $XINITRC.

Just for clarification, you are logging into the text console and then starting X with "startx"? As opposed to installing an xdm (X Display Manager) such as lightdm or slim?

Right, XINITRC, and that seems to be the expected way to configure user environments to use a customized xinitrc file.

Yes, I am start it with startx, because I got confused by authenticaiton, seats, &c.

rwp, it requires of the administartor to give all users an .xinitrc that references a site-wide file that /is not/ /usr/local/etc/X11/xinit/xinitrc .

It requires the sysadmin to set XINITRC in the global environment pointing to a locally created and customized xinitrc file.

OK, now I know some workarounds, but still am not sure why the system-wide xinitrc is considered untouchable.

Global environment? Not from the .profile script?

It's only because "pkg which /usr/local/etc/X11/xinit/xinitrc" identifies that file as owned by package xinit. What's more typical is that a port will install a xinitrc.sample file instead and leave merges up to the local sysadmin. But this package does not seem to be doing it that way.

You could submit a problem report and see what the discussion brings about with regards to that port and the handling of that file.

Thanks.

I'll note that the handling of xinit, .xinitrc, startx and such is at least 40 years old and so this is where no one wants to touch it because people will have learned to expect a certain behavior from it and won't want to break it. Even if it isn't nicely done when looking at it with fresh eyes.

All correct, especially if this behavior is not specific to FreeBSD's Xorg packages.

So... I would create a new local custom xinitrc startup file something like /usr/local/etc/X11/xinit/local-xinitrc or something. Then I would set XINITRC file in the global login environment pointing to it.

I would do that in /etc/profile.d/local-xinitrc.sh or something. That would seem to be the most clear to my thinking.

It is also possible to use /etc/login.conf to set global environment customization. But then it would need to be merged with every upgrade. So I would use a /etc/profile.d/localsomething.sh instead. Even though that only works for sh derived shells and not for csh derived shells. Because that's probably all you care about.

Being completely shell agnostic and operating before the choice of shell and across all of them is why some people would prefer /etc/login.conf which would work with any shell. Does login.conf have an .d/*.conf include mechanism? Looking...

Not really. The user can have a $HOME/.login.conf file. But then the user would just set the variable in their .profile or other file directly.

Like I mentioned most of this process flow is at least 40 years old. It's been a hodgepodge of exactly what you see for as long as I can remember. It's not FreeBSD specific. It was exactly like this on HP-UX when I was using it in the 1990s for example. This is all inherited from X Windows directly.

And no one wants to change it now because it would assuredly break someone egregiously. Instead it is better to just work within the system presented.

I don't know why the xinit package doesn't do like other pkgs though and install a .sample file owning it completely and copying it to the base file name only if the base file name does not exist. And then leaving merges to the local admin after that.

I mean it isn't like that file is changing any after decades.

Because if it did that then what you did would have been the totally expected behavior and things would have worked just like other configuration files from other pkg ports packages.

anyone with some connections to a ports committer, can you ask to push this? It's crazy the patch is done and the maintainer has to wait so long on a security-related update. bugs.freebsd.org/bugzilla/show_bug.cgi?id=291543

The man-page for sh <man.freebsd.org/cgi/man.cgi?sh> does not mention /etc/profile.d . I guess it is invoked from /etc/profile . Many thanks for the detailed explanation, rwp.

/etc/profile:19: for _file in "${_dir}"/profile "${_dir}"/profile.d/*.sh ; do

No need to guess

vkarlsen, guessing because I have no FreeBSD machine at hand. I can read (and even a little write) sh :-)

But I am still very clumsly in the terminal in general. For example, withought the help of a mouse and selection and a clipboard, I have trouble performing even the basic tasks.

ant-x: You'll get there soon :) A quick look at my /etc/profile tells me that it loads /etc/profile.d/*.sh, /usr/local/etc/profile and /usr/local/etc/profile.d/*.sh

The journey of 10,000 miles begins with the first step.

On some Linux macines at work, I have created a redistributable system with very flexible initialisation: in per-user dimension, per-endpoint dimension, global, &c.

rwp, Learning the Chinese language is difficulnt only in the first ten years :-)\

Right! Memorizing the first million characters are the hardest. :-)

As far as I know the /etc/profile.d/*.sh /usr/local/etc/profile.d/*.sh is not documented directly. It's only documented in the implementation in /etc/profile which does it. It's a text file and so simply reading the comments there documents the implementation of it.

That's actually a strength of shell scripts in that everything is easily viewed just by looking at them. Getting in the habit of looking at them is what makes working with the system easier. The man pages and Handbook can only go so far.

But anyway... /etc/profile.d/*.sh is a typical thing on other operating systems too. I know Debian's at least also implements it. Debian only implements /etc/profile.d and not /usr/local/etc/profile.d as the entire ports thing in /usr/local is rather a FreeBSD specific convention.

sh documents the sh-specific logic of sourciong /etc/profile . What's inside that file, is another matter.

Right! And so we need to browse that file and see what's in it in order to know what it does. That's always been OS specific, but mostly very similar across systems. Differences usually include local variations in PATH and umask and similar things.

Because it is sh-derived syntax specific and not for csh and not for other shells though there has always been pressure to use something /under/ that layer such as the /etc/login.conf which could be shell agnostic. But... Personally I find that process clunky and tedious.

A programming language has more flexibility.

That is, an shell script vs a simple .conf file.

Yes! Which is something I like. Which is something some people are opposite and do not like. It splits people.

systemd vs init V ?

Exactly! The systemd people hate programming and like the declarative .service files where you are limited in what you can do.

And honestly I read a lot of dislike here of FreeBSD's /etc/rc.conf file which is designed to be declarative too.

rwp, but is not as complicated as systemd.

In my not so humble opinion it is not. Because I can use "less" to browse the scripts on the system on the fly and verify what it is doing. It's all shell. Making it easier for me to understand.

But I read and write shell fluently. The people who don't like it usually don't know the shell and are faced with the syntax of it which makes it a foreign language.

/etc/rc is exemplary of trying to do the job with the wrong tool, I think. But it's one of the better implementations thereof.

Originally /etc/rc was just a simple script. You edited it and hacked it to start whatever needed to be started. It was pretty much a human edit'able script only.

Luke Mewburn wrote what is the current paradigm of it and honestly it is a brilliant bit of work.

One of the things I like about it is that I can pretty much automate processing of /etc/rc.conf and provision a new system or copy a configuration for one system to another trivially.

On other operating systems such as Devuan (non-systemd) the /etc/default/* directory of files needs to be configured. On Debian (systemd) it is a long list of /etc/systemd/system/*.service files.

So the simplicity of FreeBSD needing only rc.conf customizations is really nice!

`zfs jail` seems to be broken. It should be removed.

Oh? Please say more. How is it broken? (I have not needed to use it myself and am not familiar with it.)

one can't set mountpoints from within the jail, the zfs utilities complain that the zoned parameter is set (which is like... I'm pretty sure it should be so that you can do that?) - at least the sense works for mount -t zfs, but that means all my datasets have to be legacy mounted, which isn't exactly sustainable

maybe i'm misunderstanding how it's meant to work

I am reading "man zfs-jail" and it is confusing to me how it is supposed to be used. But it looks like it is tagging the dataset as to be managed from within the jail container. And then also requires security.jail.param.allow.mount.zfs=1 security.jail.param.allow.mount.=1 security.jail.param.enforce_statfs=2 also set to enable this.

Seems like an attempt to make a jail appear as more of a full virtual machine system able to manage child datasets below the associated one. Not something I have done. I have no experience trying to do it.

Yeah, I did all that, trouble is if I try to manage anything how one'd expect it just doesn't seem to work. I'd love to stick a dtrace in that.

I think it's going to run out of swap before it completes.

swap_pager: out of swap space

swp_pager_getswapspace(17): failed

pid 61002 (python3.11), jid 0, uid 1001, was killed: failed to reclaim memory

pid 20774 (named), jid 0, uid 53, was killed: failed to reclaim memory

Yep. . . and it took out named.

That's the number one thing I hate about memory overcommit. Other unrelated processes are sometimes killed in the collateral damage.

as in ariadne.space/2025/12/16/vmovercommitmemory-is-always-the-right.html ?

does FreeBSD have the same setting somewhere?

Upgrading PHP is a pain. A regular pkg upgrade wants to uninstall my existing PHP packages and not upgrade them/

What should I be doing instead?

Surely it uninstalls the old ones and installs the new ones?

nope

just unistalls the old ones

Are you going up a major version?

yes

8.1 to 8.2

That is a pain, partly because the pkgs don't map directly from 8.1 to 8.2

the package name changes pkg doesn't have any idea that phpX-* has anything to do with phpY-*

It's a chore to have to take an inventory of all the php ports, pecl ports, and the php apps themselves. Even then I still manage to forget something. There must be some way to do this that's not so painful so I don't keep putting off the major version upgrades :)

that does seem silly... have not hit that before, probably because any php+mods installed are deps of another package so gets handled automatically

why are you using php? required by a pkg or a custom app installed outside of pkg?

you should follow the UPDATING entry for 20240529 and use pkg set --change-name just phpX instead of pyX

PHP shop, lots of PHP apps both from ports and custom built ones

Roundcube mail, davical, phpmyadmin, etc...

I would post console output to show what it's doing, but privatebin is PHP :)

hm, as the default php version in ports is higher, do you build your own pkg repo? how about putting your custom apps in an overlay, so that you don't manually install any pkgs with a phpX prefix

Yes, I build my own repo: pkg.ent.morante.net/poudriere/build…e-saturn&build=2026-02-01_01h31m16s

lots of ways to solve... handholding the pkg upgrade and being careful is least effort :D

yeah, pkg -qo, then doing a diff afterwards :)

Fun... www/privatebin didn't get rebuilt to use the new default php version

it still wants to pull in 8.1 as deps

Can I force poudriere to re-build a specific package?

putting each web app into its own jail can help too, with security and managing deps

have a dedicated jail for a reverse proxy/https termination like nginx

firewall rules between all jails/host system/lan

I do the per-jail thing with my newer servers. It's more stuff to update, but yes, it results in less stress/breakage.