is python39 the default, or is that a downstream change

AmyMalik: python 3.9 is currently the default in ports

yes.

that does mean some ports can't be upgraded, like gajim.

jbo: around?

My laptop is wheezing. I should create a vm on my main hypervisor

is it just me or is everything about ports set up to make being a ports maintainer as annoying as possible

trying to testport my new port, poudriere wants to build 304 packages

including rust, gcc12 *and* llvm

so i have to sit here for like 12 hours while it does all that shit when i could just 'make install' in 30 seconds?

it might be

no wonder there are no fucking ports committers if this is what it's like

oh you want to test that one line change to a Makefile? sorry you have to run your cpu at 100% for 12 hours while testport decides if it's ok

i hope this is just a case of you holding it wrong, because if it isn't, rrrryikes.

-shrug-

[main-sublimemusic] [2024-01-26_01h21m51s] [parallel_build] Queued: 304 Built: 146 Failed: 0 Skipped: 0 Ignored: 0 Fetched: 0 Tobuild: 158 Time: 00:11:46

did i type the command wrong?

i have to look up that command, don't i

[1& 146? 8!] root@ilythia /poudriere/ports/sublimemusic

# poudriere testport -p sublimemusic -j main audio/py-sublime-music

this bad girl? man.freebsd.org/cgi/man.cgi?query=p…ion=8&manpath=freebsd-release-ports

Title: poudriere-testport(8)

i see

fuck testing this on 14.0 and 13.2 as well to be honest

i will just not submit the port if that's a requirement

what CPU do you have

CPU: AMD Ryzen 7 5800X3D 8-Core Processor (3400.08-MHz K8-class CPU)

ah

do you have a 5950x laying around somewhere

won't help with the underlying problem, but might make it a little easier to deal

why would i have an incredibly expensive CPU just lying around not doing anyone

valid, I guess

do you have a copy of what you're working on somewhere

AmyMalik: le-fay.org/tmp/30d/0001-audio-subli…-port-GTK3-desktop-client-for.patch

interesting programme, ngl.

I am not a poudriere expert. I'll have to leave this to someone who knows poudriere and/or is with portmgr. Before I go: who asked you to do testport?

AmyMalik: i would always do a testport before submitting a new port, i think this is pretty standard

lw, never tried it but there is a '-b branch' option that 'Fetch binary packages from a binary package repository instead of building them' man.freebsd.org/cgi/man.cgi?query=p…ion=8&manpath=freebsd-release-ports

Title: poudriere-bulk(8)

hrm, very hard to use the freebsd installer without a down arrow key

vi keys don't work

ctrl+n would be emacs key

that doesn't work eithr

some menus you can pgdown and then up arrow, but dialog doesn't seem to be one of them

how about navigating selection with the tab key?

works most of the places, not the partition editor

have to arrow down to choose the partition,

gotcha *nods*

sadly, bsdinstall(8) doesn't seem to mention about vi bindings: man.freebsd.org/cgi/man.cgi?query=bsdinstall

Title: bsdinstall

i tmux-ed from my phone. but god damn.

i suppose something to automate later

Hi, I'm trying to write a service for my script to restart if it exits. I'm using daemon(8) with -r to make it work. However, I'm encountering an issue with stopping the service. As you may have guessed, it gets stuck when stopping the daemon. What am I doing wrong? here is my service:

Title: PrivateBin

did you really expire the paste after only a few minutes?

Don't know why it has expired, new link: spmzt.net/privatebin/?6009b6596beee…JbRRZXhGMXjXqcaRziNxDpdvK88qWTh2ieQ

Title: PrivateBin

does it stop properly without daemon -r

no, it does not stop properly

i think you need to tell your bash script to handle the exit signal

i believe the keyword is `trap'

It does not help if I use the pid of script and proname of sh either. the inotify inside the script will continue to run. but the service stop with rc works.

I have tried the trap to handle exit signal. I have used the trap to kill the whole process group and/or shell script itself. Unfortunately, not even that works.

sounds like a problem with the inotify

did you use the trap to kill inotify?

I had tried the 'trap "kill -- -$PPID" TERM', 'trap "kill $$" TERM, and other variations of that, I have tried the '-T' option with shell too.

uh

$PPID ? what

I need my shell to pipe the stdout of inotify to other program. So I used group command '(inotifywait ... | program )&' and then tried to trap 'kill $!'. Same result.

you want to capture the pid of inotify in your script and trap to kill it explictly. not sure you have it in scope like that later on

daemon, PPID of the shell script should be daemon(8) itself. I have checked this before, so i'm sure about that.

ok, what happens when you `service watch stop`

watch may not be the best name as there are at least two utilities named watch already, one of which is /usr/sbin/watch

9:23 < rtprio> ok, what happens when you `service watch stop`

Noted. let me check. Will use logger to see what happens

and you trap from your shell script /root/watch.sh to kill $ppid which is th daemon pid? that's not right

trap everything in watch.sh and log it so you can see what's happening

i'm not familar enough with rc magic functions to know if i

what youre expecting to happen when you `service watc hstop` is actually happening

Has docs.freebsd.org/en/articles/rc-scripting been mentioned yet?

Title: Practical rc.d scripting in BSD | FreeBSD Documentation Portal

good call

i should go to bed

I was trying to kill the whole process group and the process group id is same as its leader which is daemon(8). So no I know the rc will kill the daemon If i pass its pid (-P in daemon) to it. In this way I was able to tell all processes under shell script process group to kill themselves

rtprio: thank you for your time.

spmzt_: procctl(8) has some reaper stuff that you might find useful.

debdrup: Thanks, will check

hi, i'm on 13.2-RELEASE-p8 ; it's a very standard box, i'm a beginner at bsd too. i have done an upgrade using freebsd-update fetch and freebsd-update install. to be sure i've also rebooted and ran pkg upgrade

but every time i try to run vim i get this: ld-elf.so.1: Shared object "libncurses.so.8" not found, required by "vim"

Dieterbe: hi, what is your 'pkg info vim' output?

hi! uh... pkg: No package(s) matching vim

that's interesting

interesting, maybe try to install it with pkg?

ok, now vim works.. strange, /usr/local/bin/vim definitely existed

thanks for your help spmzt__

Title: Chapter 26. Updating and Upgrading FreeBSD | FreeBSD Documentation Portal

debdrup: that's fantastic, thanks

nmz: sorry, I think I lost context for the conversation.

i have a command I which to run as a service. How do I write a service ?

s/which/wish/

dmr104: docs.freebsd.org/en/articles/rc-scripting

Title: Practical rc.d scripting in BSD | FreeBSD Documentation Portal

debdrup: you recommended daemon

as a replacement for runit/services

dmr104: daemon(8)

a service != supervision, but a service can be supervised.

Do we have an example of something that already uses daemon(8) that might make a good example of its use?

grep -r daemon /etc/rc.d

Like your nick I don't see anything but other string matches that mare unrelated to daemon(8). :-)

if you install 'redir'

its script that is very small will be /usr/local/etc/rc.d/redir

as an example :)

mysql-server:command="/usr/sbin/daemon"

so that uses daemon

Until this time I have been very happy using "monit" to monitor hostile Internet facing services that sometimes get abused and wedged up and then automatically restart those services if needed. Mostly for use with Apache. Nginx has not needed it.

I normally bodge a quick perl script together and run that in daemon

Reading the docs on daemon(8) it looks like it will take a program which is not intended to be a daemon and detach from the controlling terminal and background to become a daemon process, and then will restart the process if it exits. Which is completely different from what something like "monit" does to check on the health status of a service and automatically take action. Different things.

optioanlly restart it

If I want to write a daemon process then I usually just write it as well so that it is built into the program itself. That's why I haven't ever needed something like daemon(8) myself.

its kinda handy for those one off perl or curl commands you want as well

Most daemon programs also include their own process management, like Apache, Nginx FPM, and so forth.

daemon perl -e 'random crap'

you can control daemon(8) with signals

For "random crap" I will mostly just let it run in a window pane of my tmux terminal session manager which is itself a daemon.

well when you want to shove it in /etc/rc.d/local daemon is there for you :)

I'll just note that when I have wanted that type of thing that I have always in the past used setsid(1) from ports (and util-linux on other systems).

fair dos'

do's

setsid(1) does not restart but does do the daemon setup detaching from the controlling terminal.

On other systems, ahem, systemd systems, there are often problems with Apache and therefore I have taken to just letting Monit start Apache even at boot time. It just works out simpler that way.

It's totally crazy (and I know OT here) but apachectl calls systemctl and systemctl calls apachectl and the loop is broken with an env variable and sometimes, always, quite often anyway, systemd becomes confused about Apache processes. I have spent way too much time debugging systemd as to why. Now I just let Monit deal with it there. And now I am going to stop talking about OT things. :-)

fix it by using nginx :P

Nginx is awesome! And pretty much shrugs off "slowloris" attacks which put Apache into distress.

its still vulernable to that crap?

Yes. It's still a problem. For Apache. Not really a problem for Nginx because it is so light that it is just very difficult to overload a system with it.

not a problem because it uses actual forks and then soft forking / events

I just really enjoy working with Nginx much more than Apache that whenever the topic comes up I always sing the praises of Nginx hoping that over time use of other lessor systems will decline to the point where I won't need to work with those others anymore.

Iirc the most efficient mitigation is ratelimiting TCP handhakes using the firewall

For the lurkers here is a reference: blog.qualys.com/vulnerabilities-thr…vulnerabilities-on-web-applications

Title: Identifying Slow HTTP Attack Vulnerabilities on Web Applications | Qualys Security Blog

And also: blog.qualys.com/vulnerabilities-thr…o-protect-against-slow-http-attacks

Title: How to Protect Against Slow HTTP Attacks | Qualys Security Blog

I must spend some sprint time doing real work for a while.

if i bind the address 0.0.0.0:6601 using socat for example, how do i unbind it ?

kill socat

ah thanks