i see!

and yeah i think its kinda screwy. wouldnt be able to afford as much storage as i have otherwisethough

I am NOT recommending here but I have used Amazon's EC2 and I have been able to rescue a failed system by mounting the block storage on another VM. And can also write block storage with arbitrary images and then boot them. It's actually pretty flexible. But there are other disadvantages there.

i seee. and yeah ive heard disadvantages from amazaon too... namely the price

Vultr is good for FreeBSD.

yeah i tried vultr at one point

it was terrible but it was actually OPENbsd

maybe ill try it again once i get more money

I wouldn't recommend it if it were terrible, but to each his own.

yeah

the issue i think was server ram anyway

they advertised me 2gb but i got only 1.5

or 6

It's not just the price/cost for Amazon. Which is impossible to budget for. Impossible to predict costs. The problem is their feature set is for a target customer and most of us are not it. So it has a lot of features that other people like. But are missing features that most of us here want.

yeah that too iirc, ive forgotten since i havent read on what amazon does in a while

what do you think the biggest issues are in terms of features btw?

It's been prepandemic since I have done any development on Amazon EC2 and things keep changing. Having said that they never used to support console access. Which means that if something goes bad on a persistent VM then the only way to debug is to shut it down and mount the block storage on another node and view the logs for clues. That's painful. I think, not sure, but I think there is a way to get a console now?

what

that sounds so weird ngl

But they are targetting large customers who want to have a "scale-out" system with an elastic set of nodes that spin up and down with load. In that environment all nodes are disposable. You never debug a node. Just discard it and start a new one.

Amazon is often slow to adopt what I will call basic things. Like system console access. But a decade ago the problem was they were one of the last to support IPv6 for example. Which is important and was important then too. Of course now they have supported IPv6 for years. But they were a late adopter from the hosting vender side to support IPv6. Strange.

Now it seems like they are targeting the young rising star developers who did not grow up with networked computers themselves but want to have a cloud provider host them. It's serverless-hosting with lamda and a collection of other serverless hosting services from Amazon that all the cool kids are using these days. The entire concept of maintaining a "server farm" like we might think of is considered very obsolete thinking there now.

I see. I'd honestly not mind owning a server farm at all even i'm still in school

okay, i backed up my whole server now

I like to know how things work. I like understanding it. I like being able to control my own destiny.

me too, hence why i use free operating systems to begin with.

i think i geniunely got dumber when it concerned my understanding of computers when i used windows for a few months after mostly using freebsd

Using hosted serverless services has many advantages. But also disadvantages. Mostly cost based. I know people who have gotten burned with a big unexpected bill due to things getting expensive very quickly and unexpectedly.

i see

usually if it like blows up in populaity right?

i really don't like the term "serverless". i understand where it comes from, but it's really not accurate

yeah that too

"the cloud is just someone else's computer" and whatnot

I agree but that's the terminology so I am using it to identify it too.

sad but true

Since I am getting poked I will also say that I totally HATE the Amazon documentation. Looking for actual information is always reading a long series of documents each of which will reference five others but not give the answer. So I will follow each of the referenced links and read them in detail. They are the same. No information. Several reference links.

Eventually I will have spent a day reading everything available and the only references links left point back to the documents at the beginning in a circular loop. Endlessly circulating the link loop looking for the answer and never finding it.

sounds awful tbh

vultr specs might be lying to me but at least their documentation didnt

same thing with digitalocean

even some of their outdated tutoials still helped for freebsd stuff

guys, on the bare console, how can I use the touchpad supported by the hmt driver?

I am talking about this: man.freebsd.org/cgi/man.cgi?hmt(4)

Title: hmt(4)

I can use this touchpad after I load sway, but if moused doesn't support it, how can I use it on the bare console?

it looks like it creates a /dev/input/event* device, but moused doesn't support /dev/input/event* devices, as far as I know.

Oleg, I want you to know that I am not ignoring you but that I am one of those people that set moused_nondefault_enable="NO" in rc.conf in order to disable the mouse in the console entirely making me the worst source of information on it. (shrug) Good luck though!

I might ask some basic questions though. Does "kldstat | grep hmt" show the driver as having been loaded?

The man page for hmt says "To get multi-touch device working in X(7), install ports/x11-drivers/xf86-input-evdev." which is for X but probably is useful to know later.

As I said, the hmt driver itself is not a problem. I can use the touchpad when I load sway. I am talking specifically about the bare console environment

but it looks like that unlike the psm driver that doesn't rely on event* devices, the touchpad loaded through hmt.ko is accessed through an event* device

rwp: I already know I'll be able to easily use this touchpad in either a wayland or X environment. But I want it to use in the bare console environment too.

I understand. But I don't have any more suggestions. Sorry. (I disable the mouse on my console. But I am supportive of you trying to make your touchpad work.)

now all my systems are on 15.0 except my fileserver

when unbound starts it makes a bunch of connections, probably for root server cache lookup, even though i only use forward-addr. how can i disable it?

is there a way to have pfctl -s state -vv print on one line ?

or does anyone know of an awk script that can match the IP to the ID of the state entry ?

since the output is on multiple lines it's not trivial to do that :|

new pkg issue just dropped: freebsd/pkg #2259

Title: multi-repo: provide PPA like functionality where a single-package-repo pulls dependencies from elsewhere · Issue #2259 · freebsd/pkg · GitHub

found a solution, leaving it here in case it's internet searchable and others may need it

pfctl -s state -vv | tr -d '\n' | tr -d '\r' | perl -pe 's/all/\n all/g'

nice

aaand, another one: freebsd/pkg #2260

Title: multi-repo: pkg install package-name and pkg install origin/package-name come to different conclusions · Issue #2260 · freebsd/pkg · GitHub

2260 – PPP logins using PAP to Nortel/Shiva systems fail - FDIV050 bugs.freebsd.org/bugzilla/show_bug.cgi?id=2260

Title: BSD Now 551: The Story of Port 22

I have a weird problem .. hexchat and some other (GTK?) applications will spend a *long* time calling close() on all possible file handles (462285 times, which is my current open files limit) during startup. This takes several seconds.

Doing ulimit -r 1024 before starting the program reduces the number of close() calls to, well, 1024, and startup is fast.

luna_: really curious to learn how/why GCC uses Clang

It's first time I've installed node.js and pm2 in my FreeBSD jail. Is there any test/demo application, so that I could check if everything really works?

tercaL: The only one that comes to mind right now is uptime-kuma, pretty nice if you have services you might want to monitor. Out-of-the box it says it doesn't support FreeBSD, but I certainly have it working in a jail

How does a 1wire device on a Rasp Pi show up in FreeBSD? I have instructions for Linux that say to look at /sys/bus/w1/devices/28-*/temperature, but that is obviously a Linux thing. Is there a FreeBSD filesystem equivalent? Some kld I need to load to make it show up under /dev somewhere?

I'm trying to get at DS18B20 sensors.

when unbound starts it makes a bunch of connections, probably for root server cache lookup, even though i only use forward-addr. how can i disable it?

jmpp: Thanks a lot, great suggestion. I've been playing with it since your reply here.. The only thing I have to solve is, I couldn't set this environment in my jail: PLAYWRIGHT_BROWSERS_PATH=/nonexistent for uptimekuma to work under FreeBSD.

I have created a rc.d script for /usr/local/etc/rc.d/uptimekuma, and added it into rc.conf file, service start/stop commands do work correctly, however because of the environment I mentioned above is not set, my daemon doesn't want to start. Here is my rc.d file:

Title: Mozilla Community Pastebin/QsmoDLKd (Bash)

tercaL: I'm about to paste you my rc.d script for it

I even have: uptimekuma_env="PLAYWRIGHT_BROWSERS_PATH=/nonexistent" in there. Still doesn't work, any idea?

only that the bsd.to pastebin doesn't seem to be loading

jmpp: Thank you.

Title: Mozilla Community Pastebin/XZnf4SPW (Bash)

I'd love to learn -generally- how to set an environment for a jail that gets loaded each time when a jail starts.

it's amply commented, and with a couple improvement suggestions sprinkled here and there

tercaL: I don't quite know about startup-time environment variable setting. I record my desired environment in /usr/local/etc/rc.conf.d/$service files, and manage my jails via iocage

with that rc script, the only setting I need is uptime_kuma_enable="YES" in /usr/local/etc/rc.conf.d/uptime_kuma

jmpp: not in /etc/rc.conf?

I try to keep every local configuration in /usr/local/etc, which I mount into my jails, to try to make them as disposable as possible

I'd loved to use /usr/local/etc/rc.conf, but, strangely enough, rc doesn't support that out-of-the-box, not at least without a suitable edit to /etc/rc.conf, which then defeats the purpose

I'd love to use, I meant, of course :P

your rc script is remarkably similar to mine, you should be able to get the service running without much hassle

for me it's been running fine for a good number of weeks already, only showing some odd behavior when I try to restart it upon tweaking its configuration

thanks for your comments jmpp, in my script, this line doesn't seem to work: uptimekuma_env="PLAYWRIGHT_BROWSERS_PATH=/nonexistent" - would you give any clue on this?

noted your script as well, to later check it out

: ${uptime_kuma_browsers_path:=/nonexistent}

eval ${name}_env="\"HOME=${uptime_kuma_home}/data PLAYWRIGHT_BROWSERS_PATH=${uptime_kuma_browsers_path}\""

I pass the setting to the process' environment

name=uptime_kuma, also required by the script at the very top, of course

jmpp: And all the files/folders in /usr/local/uptime-kuma/ should be owned by uptime_kuma user, right?

actually, just the data directory

which is what gets written to

everything else I have it owned by root

and, of course, the data directory gets mounted into my jail, again for runtime data preservation and making the jail disposable

jmpp: Tried your script and it worked, however when I type: service uptimekuma stop, it stops (ps doesn't show it anymore) but the tcp port 3001 still open it seems, according to: netstat -anf inet

I think that's the exact problem I saw

there are 4 lines with tcp4 and 10.10.10.3.3001 - is this expected?

Title: Mozilla Community Pastebin/tcrrpjmu (Bash)

that gets written to the log, over and over, but I couldn't figure it out

I don't recall checking netstat, however

jmpp: I think I found why it happens.

sweet!

please do share! ;)

My Internet browser (myip:3001) was open and minimized

and I think it always connects and keep the connection to the jail server even after the service is stopped.

I closed my browser and restarted my jail, restarted uptimekuma, stopped it again, tcp listenings are gone

Whenever there is a browser tab open and connected to ip:3001, even after service uptimekuma stop, your jail still listens 3001 port as long as that browser is open.

I'm looking at the output of sockstat, and it shows me a collection of unexpected open local ports...

jmpp: Thanks to your logging stuff, uptime-kuma.log, this line helped me to find it:

2024-03-21T23:11:30+03:00 [SOCKET] INFO: New polling connection, IP = 88.22.xx.xx

but, of course, those become expected when you take into account the monitors you have setup, and the destination of the associated tcp connections

while I was wrestling around it.

so that explains why those ports remained open in your case...

Yes, indeed. And in your case, not?

something else you got too?

but, did you happen to see those log error entries in the last pastebin I shared?

Yes, which file have you got them?

uptime-kuma.log?

tercaL: I don't recall seeing anything strange regarding open ports (cf. my comment just now about sockstat), but I did end up frustrated at not being able to solve that crash I'm referring to

data/error.log

I also wanted to point all uptime-kuma logging to the /var/log location, but didn't manage to

the latter is used by daemon(8), per the rc script, but data/error.log is used by the uptime-kuma process proper

jmpp: Oh, got them as well, it seems:

here pastebin.mozilla.org/48fBzqpU

Title: Mozilla Community Pastebin/48fBzqpU (Bash)

that error would occur when trying to restart uptime kuma, causing it to hang and require a kill -9

yeah, bummer

I did a code dive into the JS code, but real life (*cough* and my distaste for JS code *cough*) kicked in real quick

so I didn't pursue it much

jmpp: i.stack.imgur.com/7hsmo.png

"I finally got it working by setting the Connection header to be keep-alive to the tests that has that write EPIPE error." says a user from stackoverflow

right, but why was it occurring upon recycling uptime-kuma?

somethign was writing to a socket... which socket? uptime-kuma's 3001 tcp socket? Something else? And what was writing to said socket? And what was expected at the other end of that socket that was no longer reading the data?

tercaL: where was that tweak added?

jmpp: Still reading around.. the comment was here: stackoverflow.com/questions/6943037…st-tests-on-gitlab-cis-personal-vps

Title: node.js - Error: write EPIPE when running Jest tests on Gitlab CI's personal VPS - Stack Overflow

right, but in that context you know who's writing to the pipe, the test, and who's reading from it, the backend that's being tested, so the header was added to the test for the backend to not close the pipe

in uptime-kuma's case, I was not able to discern those players

I only figured uptime-kuma was the one trying to write to a tcp socket, hence its complaints in the log

but, again, what socket was it trying to write to? tcp:3001? If so, could that indicate an incorrect shutdown sequence...? I don't know

if so, perhaps daemon(8)'s -p Vs. -P might resolve the problem, but I don't recall thoroughly testing them

rwp: this code was the solution to the problem I was having; it works great: github.com/wulf7/moused

Title: GitHub - wulf7/moused: Moused with EVDEV support

Oleg, So the answer is an enhanced moused? Or is that a small patch to the existing moused? I am trying to catch up now.

I guess it is both things. It's an enhanced moused and also there is a patch for Bluetooth mice.

Oleg, I am glad you found a solution for you! And thanks for telling me the answer you found too. I am taking notes. :-)

what do you mean "enhanced"? it simply supports event devices provided by evdev.

I would call that enhanced if it does this but the in base moused does not do this.

Otherwise the one in base would be sufficient.

Ltning, That's an interesting observation about hexchat closing 462285 fds at start and the ulimit -r 1024 workaround for it. That seems like a bad design choice in the code to the point of being called a bug.

When starting up a daemon the typical procedure is to close all open file descriptors. Which the program does not know. What file descriptors are open? No idea. So the typical thing is to close the first arbitrary N number of them from 0 through N. Where N is something that might be 256 for the super paranoid but only 10 for the good-enough case.

There are a bunch of ways to get the number of possible file descriptors. FOPEN_MAX, OPEN_MAX, _SC_OPEN_MX, and so on. But none of them are suitable because of the problem you described.

The reason for this is that children processes inherit the parent's open file descriptors (a useful feature) but then if they are going to go their own way they need to sever ties and fly off on their own. It's not unusual for shell scripts or emacs inferior shell processes or other perl, python programs to have a couple of open file descriptors at the time that they launch a daemon. That's what needs to be closed.

jmpp: May I ask why is "uptime_kuma_group" set to 'staff', and not to uptimekuma user's own group itself?

rwp: ok, so this is hexchat-specific? Or gtk-specific? There are a few others that do that - nextcloud-client for example, at least it used to. I can't remember off the top of my head which others.

It's unlikely gtk, since most of my stuff is gtk (windowmaker+mostly gtk applications)

I assume it is hexchat specific. But one would need to look at the code that is doing this.

When I heard you say that it was closing all possible file descriptors, I have seen code becoming a daemon doing exactly that action. But it shouldn't try to close ALL /possible/ open file descriptors but just the likely ones.

It's preceded by "getrlimit(RLIMIT_NOFILE,{ cur=462285,max=462285 }) = 0 (0x0)" in the truss output, then it starts closing from 3 upwards.

That sounds to me like a program that is trying to close any open file descriptors but does not know that so closes all of them, which a program should not attempt to do.

You had a very clever workaround to use ulimit -r 1024 to limit the number of possible file descriptors. I thought that was very clever.

It's fine for hexchat, it's unlikely to need more

But for something like nextcloud-client, or anything else that does file/directory watching, that's nowhere near enough

Normally a program has stdin 0, stdout 1, stderr 2, and then sometimes will have 3 open because the parent is reading a config file and has 3 open there. A child needing to daemonize will need to close those in that case. Otherwise the lowest open one will become the controlling terminal for the process.

And at least on 13 (I think), while it's doing that nothing else really works. On -CURRENT at least other applications still respond reasonably well.

hi everyone, why does ALT + SHIFT + > or ALT + SHIFT + < show up as ISO_Next_Group on my setup

i dont want this

Ltning, For nextcloud-client I would think 1024 would be quite a large enough number but could see it needing more. But 1024 is quite a few!

yaslam, I think, not sure, but think that those keys in XFCE for example will shift workgroup rooms left and right.

yaslam, How are you observing those keys? Why are they causing trouble? When I run xev to look at the keysyms here I only see < and > and not ISO_Next_Group here.

ah nvm fixed it, turns out MATE desktop was using them for switching the keyboard layout

Ltning, I just think that any program should not be trying to close /all/ file descriptors. I think that is a bad design choice, bad to the point of being a bug. And could be fixed. My programs which I write to become daemons only close 0 up to 255 just to be paranoid and that is it.

yaslam, Okay. Good to hear you have this resolved. And this sounds like something I would never run into here. But I am happy you have it solved now. :-)

Ltning, I probably should not mention this because it implies a certain old thinking but... When I started using Unix the maximum number of file descriptor possible were 20. That's right. 20. Who would need more?

Then it was raised to 60. And then to 1024. And I remember working on HP-UX when a patch came through that a customer needed it raised to 20480 and it was a big deal. So seeing 462285 possible seems extremely huge to me.

rwp, thanks

rwp: I think maybe on 14/current it autoscales somehow? I also find 400k to be a pretty big number..

I am sure it is not a fully allocated array as it was in the earlier days. But it still seems like a very large number of possibly open files. That would take a big memory machine to support that possible case.

Also sometimes these system changes cause software that was not buggy at one time with lower limits to be exposed as buggy later when the limits are large. If the limit was 1024 then your example hexchat and any program could for loop close through 0 to 1023 very quickly no problem. But raising that to half a million then suddenly that program which was good is now bad.

The Hurd kernel tried to get rid of all arbitrary limits. That created a lot of problems for software porting to hurd in that things like this then might fail miserably because the number was unlimited effectly limited only dynamically by running out of memory.

tercaL: I wanted to use www:www, but I experienced some strange hanging issues which I also couldn't figure out (could have been mixed with problems due to so many other changes I was doing at the time)

so, ultimately, I put in a comment to attempt a switch to www:www again once things had settled down

which they have now, for sure, but I just didn't get around to it

so I just left the user:group at something temporary

I think this github.com/fubarnetes needs to be added to wiki.freebsd.org/Containers

Title: fubarnetes · GitHub