Hey .. Can anyone think of a way to check if a running daemon is the same version as the one installed on disk? I need to find out if a service has been restarted after replacing the binary, but restarting the service unnecessarily has significant side-effects..

Hah, 'procstat binary <pid>' spits out 'procstat: sysctl: kern.proc.pathname: 8005: No such file or directory' on stderr if they differ. Still returns 0 though. That feels like a bug..

Attach a debugger to the process, and try find some kind of version symbol. Examine the start time of the process, vs the creation time of the file - if start is before, its old version, otherwise, new version. And probably many other ways.

Nope, 'procstat binary' is the easiest, and needs no special privileges. :)

Try 'procstat binary $$ ; pkg upgrade -y <your shell> ; procstat binary $$' - if pkg upgrades your shell binary, the second invocation will return an error (but also exit cleanly, which is a bug imo)

So fix it. Should be easy.

Yeah, starting by raising a bug report

Still, serves my purpose. :)

Yep

HI

Hello

little problem here.. ah I enabled amdtemp driver to check my cpu temp.. but it returns some weird info

Not familiar with that at all

it returns 15C which is so weird for AMD A4-5300B

yeah, seems pretty cool

crazy it's summer here +40C

I noticed somethings are like that in FreeBSD... Like my fastfetch will say I'm using 40% of my ram, but btop will tell me I'm using 3%

I searched everywhere, and come with some freebsd bug reports about it.. bugs.freebsd.org/bugzilla/show_bug.cgi?id=233764

"A8-7600" similar to mine.. all end with this "It seems that the processor is already EoL'ed many years ago... we want to focus on supporting newer processors and new hardware, so close this as WONTFIX unless someone can provide a patch.

amencoda: sysctl -n dev.cpu.0.temperature returns the same

7.5C now!?

does your BIOS have ability to show temperatures too, to compare the sensor reading ?

was going to ask that

wait let me check

In Windows 10 2 of my cpu sensors are constantly pegged at 100C. But luckily there are many other sensors and I have a pretty good idea when it's actualy all total around 50C at idle or 80C when playing Cyberpunk 2077

but as I see it's very popular bug google.com/search?q=amdtemp+wrong+read+freebsd , also I was on windows the temp is normal 70C.. anyway I will check

fixing it only for newer hardware bugs.freebsd.org/bugzilla/show_bug.cgi?id=218264

imgbox.com/skOipGvP probably difference between buffers and cache memory and actual app usage

like in this screenshot*

mosaid: I heard something about older AMD cpus that they report trash data below certain temperature, 30c or something

not sure if it still applicable

yeah true

a bug in freebsd not fixed see above

I am asking for fix

I feel freebsd isn't interested really in older stuff.. especially old hp Compaqs

Hello, all. As the number of customisations and scripts I use in my FreeBSD grows, so does the need of a discripline in their orgranisation. Where do you keep system-wide cronjobs? In the administrator user's crontab, or in root's ?

15.1-rc3 hath ben posted

Hm... if I have 'block drop quick inet6 all' at the very top of pf.conf, and set skip on lo0 later on, why does 'ping ::1' work? is 'set' treated differently from other rules? I was expecting it to stop at the block.

'(pass|block) on lo0 (inet|inet6) all' as last rule does the job but still curious.

This is how I waste my time when I'm waiting for a pkg build to finish

Hello, all. How cam dma (the standard MTA) access its config at /etc/dma/dma.conf, ownded by uid:root and gid:mail, when run from my user and, who is member of groups www and ant?

I myself can't access that file without sudo!

is it a suid binary?

it is a setgid binary

The file permissions are: drwxr-xr-x .

From: doas ls -ld $(which dma)

Perhaps its sendmail binary is suid...

sendmail is an alias for mailwrapper which calls /usr/libexec/dma which has "-r-xr-sr-x"

Nope: lrwxr-xr-x 1 root wheel 11 Nov 28 2025 /usr/sbin/sendmail -> mailwrapper; -r-xr-xr-x 1 root wheel 8632 Nov 28 2025 /usr/sbin/mailwrapper

which dma have you in path?

satanist, all explained: ls -ld $(which trolol) # reports drwxr-xr-x, too!

Because I forgot the quotes.

also why -d for a binary

For generality :-)

What's libexec? Why is not in /usr/bin ?

because it is designed for some some tools to be executed but not by the user directly

libexec is very nice, it allows the main binary to be dispatch for smaller binaries or scripts, eg 'git diff' => /usr/local/libexec/git/git-diff (not saying git works like that tho)

Makes sense.

Althought dma does not such thing, yet I see how it belongs there.

Ox1eef, it is not a feature of libexec, but an organisation meausre, right?

Right, this is just how I use it, more generally, satanist is accurate.

Satanists are accurate people >:

i have no control over what nicknames ppl choose. :)

_0x5eb_: actually git works this way

Ox1eef sorry

Hmm cool

But not without Rust anymore :-)

C was not enough for Git.

Hmmm! The unorthodox root's personal crontab (sudo crontab -e) does not seem to be executed?

ant-x, use the -u option to crontab maybe? There's a note in the manual page that su can confuse crontab, and I suspect that's also the case for sudo.

V_PauAmma_V, interesting. With doas, /var/cron/tabs/root is dutifully created, but does not work... Thanks. I will rather use /usr/local/etc/cron.d now.

How does /var/cron/tabs/root not work?

Are you editing it directory, or via 'crontab -e'?

s/directory/directly/

helping.

uh uh.

given that they compared /var/cron/tabs to cron.d, i think you know the answer

:D

I was just looking at root's contrab on this old VPS: bpa.st/G4LQ

Not currently doing anything, but certainly has in the past.

CrtxReavr: -J

CrtxReavr, via `crontab -e'. Jobs from are never executed, IMHO.

zi, I am aware of the difference in the format: an extra user field in cron.d . Did you mean that?

ant-x, bpa.st/QKBQ

FWIW, cron(5) is actually the more useful manpage for cron.

CrtxReavr, <paste.c-net.org/UglierContains> .

My: /var/log/cron contains: /usr/sbin/cron[56616]: (root) USER (account unavailable)

No, it does not work for me..

ant-x: no, i did not.

ant-x: to modify root's crontab, you use crontab -e. you must not directly edit files in /var/cron/tabs/

ant-x: if you want to do that, you must use cron.d/

zi, I did not edit it directly. As I said, I did ``doas crontab -e''.

Similarly, if a do ``crontab -e'' for my normal user, the job works.

I confirm that the entry in /var/log/cron sahing "/usr/sbin/cron[65234]: (root) USER (account unavailable)" is generated by that failing root's cronjob.

ant-x: have you disabled your root account

But I don't understand what it means.

Well, I can log into it via ``doas sh''. Can it still be disabled?

my passwd has: root:*:0:0:Charlie &:/root:/bin/sh

check /etc/passwd and /etc/master.passwd for *LOCKED*

satanist, root is LOCKED in master.passwd .

I can unlock it with pw, then. But I did it as a security measure.

satanist, Thank you.

you could also just disable password login, this allows tools like cron to still use the account

That's better.

also doas still works, because it is started directly as root and doesn't switch the user to root like cron does

*by suid

But what is the difference beween `pw lock' and `pw -w no' that causes the formet to break cron and the latter to keep it woring?

(if you meant `pw -w no' as "disabling password login")

afaik doas just sets the uid/gid and runs the command, cron uses pam to do a full user switch

satanist, I mean the difference between a user locked via `pw -w no' (disabled password login) and one locked via `pw lock' (with LOCK in passwd). Why one works with cron, and the other does not?

They're not that different. 'pw lock' corrupts the password field by adding *LOCKED*, and then other codepaths look for it, and can render 'account available' based on it. pw -w otoh changes the password field, but you cant restore it.

*'pw -w no'

And why does `ps -w no' not break cron, whereas `ps lock' does?

Is it becuase it explicitly checks for LOCKED in the password field?

(before trying to assume that user?)

Right. *LOCKED* is a magic string that can be detected. I don't believe same can be said for pw -w no.

^ So, if a password is broken but does not contain *LOCKED*, crond and other tools can still assume that user, because it is not locked, despite the mangled password. Cool.

If you really want to know for sure, you'll have to check the source

as I said before cron does a full login via pam and doas just use setresgid() without checking the master.passwd file

*setresuid, setresgid and initgroups

look into mdo(1) as well

You guys are smart

i confirm

Should I be worried about CTCP Versions in other servers? I joing a IRC Bouncer server and a person who is not a mod did that to me

objectivist youtube.com/watch?v=L3HQMbQAWRc

Bob Marley was a freemason and he was taught at a jesuit school

He didn't worry about CTCP tho

I seen this guide on how to ctcp custom message

someone do one to me

90s vibes

No great worry

Ok, yeah not sure if those irc bouncers are allowed or not, I just don't want to miss chats

Bouncers are whatever

easily 33% of us have them

weaponized apophenia

what

The eye is watching you/(o)\

What makes The Eye different from other eyes

Oh right, there's only one of them. That in itself is unusual. But I've seen pirates one eye. Is The Eye a pirate?

some even have Five Eyes

lol

Perhaps it is not the number of eyes that makes a pirate, but the willingness to see beyond the law.

I think it's the hat that makes a pirate. I won't take a so-called pirate seriously unless it has a very good pirate hat.