And completely unambiguous: date "+%F %T %z"

ISO 8601 has the nice property that an alphabetic sort will sort dates in increasing order

yes, my idea of a perfect date is YYYY-MM-DD

it's a good 1 for sure

I have two hard drives , one with Windows that is set for bios and Ubuntu  , its ssd and the other is 2 tb normal hard drive  with Ubuntu 22 and Gentoo.    I tried to install freebsd  but I could never make space.  I would use gparted with Ubuntu  but that space was not seen by freebsd  partition program nor when it deleted partitions did

that program see the free space .  What might I do ?

Gone already... I'd have recommended to them to just get another HDD, it makes things so much easier

Grabunhold_, any luck yet? If not, try debuggin with the very minimal script from here: <freebsdwiki.net/index.php/Usr/local/etc/rc.d> .

ant-x: i went back to thinking about it just one moment ago :D

That is synchronicity! <fusionanomaly.net/synchronicity.html>

Re: my link: it is not the official wiki, and not entirely correct about the commenad, because it ignores the prefixed veresions: faststart and faststop. Yet it is a good idea to start from the barest minimum, wihout any external dependencies.

And of course you have to add the shutdown keyword.

hmmm, it can't be so hard to get the "normal" script working can it?

after all, the problem is not that it doesn't work when invoked - the problem is that it isn't invoked (invoken? haha. sorry, not a native speaker) at all

cause the first line in that script says "log invocation and arguments into a file", but that doesn't happen for shutdown

Grabunhold_, In my experience, the first time, anything can be as hard as you can imagine, and then some :-)

Grabunhold_, Yes, right. I am not a native speaker either.

rc.shutdown is a script, right? If it is, you can test your service by invoking it manually, according to <man.freebsd.org/cgi/man.cgi?rc.d> .

The idea is to try emulate what the OS does and hopefully to reproduce the error.

* invoked .

here is the current version by the way: pastebin.com/pqZKJUU5

^ Are you sure PATH= is sufficient, and not export PATH= ?

yes, the only reason why that's there is that my script start subprocesses via /usr/local/bin

i got a command not found error, added that line, and they went away

Is it inherited without export?

I see.

it seems so. not sure why it was even necessary in the first place

So -- try invoking rc.shutdown as per RC(8) .

i wanted to investigate that further, but getting shutdown to work is priority #1

^

hmmmmmmmmmmmmmmmm, that manpage says that rc.shutdown should be at /etc/rc.shutdown, no?

because i have nothing at /etc/rc.shutdown

maybe we're on to something here

Grabunhold_, try to find / it.

The man-page does actually say what on Earth rc.shutdown is. It may be just a name of a system mechanic... I am not at my FreeBSD box now.

oh, it -is- there. i missed it somehow

stupid

* does /not/ actually say...

Then you can add some debug output in there, too

hehe, good thing i have a test machine just for debugging this :D

Which with luck will let you know why your script is not invoked.

Well, a simple backup copy of a file you change seems enough. I broke my system yesterday and regretted not having made a backup.

do you know about bectl?

No.

well, it is great for hacks like this. but it needs zfs, iirc you're on UFS?

Grabunhold_, Yes, a old laptop with 4GB RAM. They say ZFS is heavy, needs more memory.

well, i guess it needs more ram to perform satisfactory in any way. but if you simply want to play around and don't need a gui, 4gb will do

I am rearing to know whether you have been able to invoke rc.shutdown by hand. RC(8) mentions setting the value of rc_shutdown before invoking rc.shutdown.

Grabunhold_, Why? With a lightweight wm it should be good.

ant-x: why zfs? because you get bectl, for example :D

i've inserted the following line just below line 100 in /etc/rc.shutdown:

echo "running faststop for $_rc_elem" >> /var/log/rc_shutdown_debug

...sicne rc.shutdown itself accepts an argument, I wonder what is the purpose of rc_shutdown (with underscore).

reboot commencing...

Wait!

too late :D

We need more liberalism, some log before that loop, to see which files have been found.

Also, instead of rebooting, I /do/ suggest invoking rc.shutdown by hand -- will save time.

i wasn't sure what state the system would end up in

i'm accessing it via ssh

so i went for the full reboot

Oh...

well i can walk over to the next room and connect a console should something go seriously wrong

We need to log the output of rcorder.

it's not that bad

i'm just lazy :D

interesting, no output at all

cat: /var/log/rc_shutdown_debug: No such file or directory

One must be lazy, to connect by SSH to a machine in an adjacent room :-)

ant-x: well, it's server-grade hardware and unpleasantly loud to keep in the same room as oneself

I say: log the result of `rcorder -k shutdown' which is supposed to select rc.d. files for shutdown.

I mean whatever rcorder call is there inside rc.shutdown.

also there is no gui on that machine, so i'd have to setup an irc cli client and whatnot...

I call that job a text quest, after a classic genre of couputer games, by Infocom &c.

okay, these seem to be the relevant lines: pastebin.com/PeAFHZS6

(I was disconnected)

i'll try to log the content of "files", but i have a feeling that something is wrong with my logging hack. i mean, surely _rc_elem wasn't completely empty during the last reboot?

<Grabunhold_> okay, these seem to be the relevant lines: pastebin.com/PeAFHZS6

in case you missed it

Grabunhold_, make sure to lot it onto the root fs, in case the other directory is not mounted.

Great -- it sends error output to /dev/null -- bad manners, no?

okay, so... `sh /etc/rc.shutdown`?

I wonder what the `debug' call does.

i', prepared to walk over there! :D

ant-x: yeah i was too @ debug call

tried to find where that is defined, but it doesn't seem to be a function local to that script

Well, I will take the responsibility, but with you luck...

Grabunhold_, could be sourced in.

Grabunhold_, I think you have to pass some argument to rc.shutdown.

now would you look at that! pastebin.com/DJBKkU8p

You can actully break rc.shutdown -- commenting all work and replacing it with echo's of the corresponding commands. That way, rc.shutdown will make a test run.

It works, when run manually...

By the way, it is /much/ better to refer to the raw text: <pastebin.com/raw/DJBKkU8p>

let's get the machine into a normal state again

remove the logs produced so far

and see if we can reproduce that with a "normal" reboot

Grabunhold_, what would be the difference from the previous reboot?

interesting. again, no /rc_debug_log file and no calls to "faststop" or "stop" in /var/log/anlasser/debug_stop

so i guess there must be some kind of difference in the way rc.shutdown is called during reboot (if it is called at all?)

Different arguments may be passed to it -- log them.

let's start the script with "echo $* >> /rc_shutdown_invocation"

Yes, in the very first line.

it's the first line after the shebang and comments, "reboot", "cat: /rc_shutdown_invocation: No such file or directory"

huh.

As if rc.shutdown was not called at all!

what's the problem

rtprio, cannot log the invocatio of rc.shutdown prior to reboot.

^ <man.freebsd.org/cgi/man.cgi?query=rc.shutdown>

Looks like it is not invoked.

Grabunhold_, have you played with your devd events? Could you have overriden a rule for the shutdown event under one of your etc/devd directories?

rtprio: the bigger picture is that I'm trying to stop a script of mine during shutdown. i've written an rc script, that's here: pastebin.com/raw/pqZKJUU5

start / stop works fine, and running "sh /etc/rc.shutdown" works fine and leads to the correct log lines

but doing a real reboot or shutdown doesn't. no log lines, no nothing

and i'm not sure what's wrong

and you've already read docs.freebsd.org/en/articles/rc-scripting ?

ant-x: devd config is completly stock here

Grabunhold_, check your /etc/devd and /usr/local/etc/devd for rules handling the shutdown event. If there is more that one rules, only the first (by priority) is executed.

rtprio, Yes, I went though it yesterday. The rc.d script is question is available online.

rtprio: multiple times, and as far as my interpretation of that document goes my script should work. in fact, it does work correctly when i invoke "sh /etc/rc.shutdown"

"service anlasser stop" and "service anlasser faststop" work as well

Grabunhold_, I don't know. I would really locate and log the invocation of the devd rule. One option is to stop the devd service, and run it in foreground as devd -d, then log its stderr output to file. If using grep, make sure to include --line-buffered.

so I'm under the impression that my script is correct @ rtprio

it's just that it isn't invoked during shutdown

e.g.: devd -d | grep --line-buffered 'shutdown' >> /devd.log

Am I right that rc.shutdown is invoked by a devd rules?

ant-x: no i doubt that very much

rtprio, Hmmmm, then what invokes it?

Can we log the point of invocation?

Grabunhold_: what happens when you rc.shutdown now? the daemon process is killed letting the app end?

rtprio: you mean "sh /etc/rc.shutdown"?

yes

i just ran that, it properly stopped my script

^ Which is why I wonder what calls rc.shutdown at reboot.

the anticipated "Tue Jul 23 13:32:49 CEST 2024: Anlasser Received faststop command" line also appeared in /var/log/anlasser/debug_stop

why faststop

because that's how rc.shutdown invokes the rc scripts it seems

rtprio, indeed: even according the rc.d scripting guide.

Grabunhold_: When you test rebooting, do you use shutdown -r or reboot?

see line 105 of /etc/rc.shutdown

vkarlsen: "reboot"

Grabunhold_: try shutdown -r

and 'service anlasser faststop' also shuts down your thing properly?

rtprio: yes it does

vkarlsen, Is `reboot' not supposed to shutdown rc.d scripts/deamons ?

ant-x: I'm not sure that it does

reboot/ shutdown -r is the same thing

rtprio: but even if it didn't, at least the "invoked with faststop" line should appear in /var/log/anlasser/debug_stop

see line 15 here: pastebin.com/pqZKJUU5

eh, "received faststop command"

vkarlsen: will try

ant-x: According to the manpage, it just flushes the fs cache, sends all processes a SIGTERM (and then SIGKILL) and restarts

Who calls rc.shutdown? The rc(8) program? If so, who calls rc(8)?

vkarlsen, I just read that, which is very strage. It makes reboot a dangerous command!

I thought that maybe rc(8) was called from the devd handler of the shutdown event...

ant-x: Furthermore, shutdown(8) has an option to execute halt or reboot instead of sending a signal to init

If my hunch is right, Grabunhold_'s script might be completely correct, it's just never told to shut down

vkarlsen: it seems you're right. "shutdown -r now" seems to have lead to the correct log lines appearing

i'll double-verify that

/rc_shutdown_invocation appeared as well, content is "reboot"

that wasn't there before

/rc_shutdown_debug is there now, too. and it contains (beside other lines) "running faststop for /usr/local/etc/rc.d/anlasser"

Whew! So, `reboot' /is/ a dangerous command, e.g. if you have a DB running?

Congratulations, Grabunhold_ .

depends... on how fast your processes handlie SiGTERM

I should prefer to alias or symlink reboot as shutdown -r .

ant-x: Yeah, this should be communicated more clearly, I think

e.g.: reboot and reboot --fast/unsave

*unsafe

how often are you shuting down anyhow

coming from linux / systemd, this is very unexpected. typing "reboot" into a linux machine does a normal reboot, going through the normal shutdown procedures with proper shutdown for all systemd units

Often -- mine is not server, but a laptop.

Of course, in most cases I would assume the DBMS to exit cleanly on SIGTERM, but it might take a bit too long in some cases, and someone'll be having a bad day

i've been rebooting FreeBSD systems with "reboot" for __years__ now

Grabunhold_, systemd is hated/loved. But the traditional init system probably does the same.

i never knew i was holding it wrong

Not /necessarily/ wrong, but less gracefully, as it were...

ant-x: i came up on gentoo / OpenRC. "reboot" was perfectly "normal" there, too

So have I.

i strongly suspect there is no difference between "reboot" and "shutdown -r now" on a typical modern linux system

Guys, it a case for change of reboot sematics, I think. The dangerous version should asked for, by a switch. The default should be the safe version.

it's a quite substantial footgun, i never even knew i was doing something wrong for years coming from that "other" operating system where it's perfectly normal it seems

The last sentences here mentioning reboot(8) should perhaps have a bit more teeth -- docs.freebsd.org/en/books/handbook/boot/#boot-shutdown

well, i wouldn't even have thought to look at these docs

i type "reboot", machine reboots

vkarlsen, the docs are one thing, the principle of least astonishment quite another, no less important.

That's it.

i didn't even suspect there would be a need for me to look at the docs

reboot should be `fastreboot'.

Not for `reboot', anyway.

The Handbook describes the action of reboot as: Immediately reboot the system, and instructs the reader to use `shutdown -r now' to reboot a FreeBSD system!@

Very, very counter-intuitive and surprising.

Glad I learned it.

well, immediately reboot the system. that's what i want! :D

Took Grabunhold_ two days and your help :-)

No, you want it /now/ but less imemediately, to let the services shutdown gracefully :-)

ant-x: well, i wouldn't call my stumbling along "help" in any way :D

Grabunhold_, did not rtprio solve you problem just now/

ant-x: it was vkarlsen who suggested "shutdown -r now"

Oh, then him. I thank him for the explanaiton.

ant-x: i see 2 problems with this situation. I wouldn't

a) have thought to even look at the docs for reboot. on the surface, it absolutely does what you expect it to do and only if you dig for clues and connect some dots do you even understand what is happening.

b) have interpreted "immeadiately" to mean "bypassing the proper procedures". reading that sentence without further knowledge, i would simply assume it means "without delay"

Do you mean a) have /not/ thought and b) have /not/ ingerpreted ? That about describes my experience, too.

Oh, yes I see.

ant-x: eh, i meant the "i wouldn't" to go in front of these two options

i guess i could write more clearly myself :D

oof. i could have spent days and days debugging my rc script, questioning everything in there and only getting more confused following red herrings

We can propose an improved doc, or perhaps even better semantics for reboot, which by default should be equivalent to shutdown -r how.

reboot.c hasn't gotten a whole lot of changes since the beginning of time (i.e. when rgrimes imported it from BSD 4.4 Lite in 1994). Maybe reboot had a different connotation in the earlier days?

^ on bugzilla.

Yes

if you ask me, Principle Of Least Astonishment would be to change reboot to act identically to shutdown -r, and require a flag for a fast/unsafe reboot

i'm hesistant to demand change regarding reboot. on one hand, it's utterly confusing in a very non-obvious way for us young-timers and/or folks with a background in modern linux.

on the other hand, who am I to demand change from the unix graybeards when that command has been around since long before I even touched a computer.

Grabunhold_: i didn't read backlog, but if you mean having "reboot" be equivalent to "shutdown -r now", there was a thread about that on arch@ recently, imp@ is pushing it

i'm personally mildly against it but not to the point i really care either way

lw: yeah, i just spent 2 days trying to understand why my (first-time) rc-script wouldn't execute it's stop-procedure

being new to writing rc scripts, i thought of course it must be my fault

well, you may get your wish as iirc most people were in support of this change

and somehow it was, but not because my script was wrong but because i simply used "reboot"

and to somewhat recap for you, i don't think better documentation would have helped me because typing "reboot" is complete muscle memory for me and i wouldn't have thought to look at the docs for that. especially when i'm writing an rc script for the first time and think of everything in there as potentially wrong

lw: What are your objections?

would have probably wandered off chasing red herrings for days on end if it wasn't for you good guys here helping out. thanks again to vkarlsen for the proper fix and to ant-x for staying with me the whole time, it's always better not to be alone with a problem :) <3

vkarlsen: i don't see the point of the change and i find the functionality of "reboot" useful (e.g. in single user mode, or in some other case you don't want rc.d shutdown running)

vkarlsen: but most of my Unix experience is with non-Linux systems, so i appreciate that a lot of (newer) FreeBSD users comes from Linux and this is confusing behaviour

lw: maybe "reboot" could simply print something to stdout along the lines of "emergency reboot; bypassing proper shutdown procedures" or something

that would keep the functionality where it is, but immeadiately give people like me the right hint

lw: I agree

i think i'd be fine with "reboot" simply printing an error message that tells you to use either "shutdown -r now" or some new command like "reboot -f", but that would probably break a lot of scripts

well, it doesn't have to cancel the action i guess. printing something instead of silently doing an unexpected thing would have been enough to save me from this wild goose chase

i'm okay to accept that lowest-effort solution for most users is to just make reboot behave like Linux

i'm sure that won't be difficult to get used to

at least we're not on SVR4 where you have to use "shutdown -i6 -g0", the most opaque command ever

well i'm all for that obviously, but I think we can get 80% of the benefit with 1% of the effort if we simply make reboot give the user a hint

lw: i can't find any thread on arch@, was it perhaps another mailing list? i don't care if the "don't run rc-shutdown" is called reboot or something else, i just want it to exist

Grabunhold_: if you have an opinion on this i suggest posting to arch@ about it (probably find the old thread on this and reply to it)

dstolfa: i look, stand by

dstolfa: i think i'm thinking of this thread: lists.freebsd.org/archives/freebsd-arch/2022-June/000184.html - for some reason i thought it was more recent. note that he clarified in a followup that he means reboot should be 'shutdown -r', not 'reboot -r' (which would be weird)

lw: thanks

does it make sense to revive a thread that old? i have zero experience with mailing lists

probably not, but you could mail imp⊙fo with your views and/or to ask what became of that idea

he is quite friendly

he is also pretty busy so it's possible he just forgot / never got around to it

will do :)

scoobybejesus, re: reboot == shutdow -r . I agree. Perhaps shutdown -r now.

lw, re: reboot userful in single-user mode &c. Exactly, and this is a rare case compared to the normal reboot, hence we want this minor case handled with a special --fast or --unsafe switch, or a special alias, such as fastreboot.

Is there a bugzilla ticket about it, too?

Grabunhold_, mailing lists are great, especially when used with a good e-mail client and Gmane.

well it certainly shouldn't be a GNU long option, but using the existing fastboot(8) for that should be fine

Mailing lista are essentially forums carried by the medium of e-mail: no updated browser required, not heavy JavaScript: just pure plain-text over e-mail: the most accessible option.

ant-x: but the issue here is not whether it's a "minor case", but rather whether the historic behaviour of all Unix systems (excluding Linux) is less common than what Linux users expect. i feel like this might not be the case, but on the other hand, it's easier for FreeBSD users to learn a new syntax than for Linux users to adapt.

lw, Yes, we break backwards compatibility, true. Sometimes, thougth, it should be broken. I wonder if the change will upset people using reboot. What would be the dangers except a slower effect?

also similar to how we moved to make autoboot the default, even though that might confuse admins used to the older behaviour

I think most users will not actually notice the difference between boot and shutdown -r now.

Grabunhold_, let us coordinate our efforts: I will create a bugzilla ticket, let you know. You can comment futher and forward the comments to imp@ .

lw: it's not just linux users being confused, it's also scripts written for linux. e.g. if some ad-hoc provisioning tool/script uses reboot and expects it to run rc-shutdown, it won't work properly today

ant-x: deal!

dstolfa: do you think people run Linux provisioning scripts unmodified on FreeBSD? that sounds error-prone

lw: it would not surprise me tbh

dstolfa: i use Ansible to configure FreeBSD hosts, I wonder what Ansible is doing when I'm using the "reboot" module

Grabunhold_, please, learn the usage of /msg MemoServ help . It will let us stay in touch when not online.

ant-x: i actually read your last memo :)

Great, and you send them, too.

Grabunhold_, you are registered here at #libera, but your current nick is not registered to you. You can do so by /msg NickServ group .

It will let me send memos to this nick.

Grabunhold_, can you wait a couple of days till I file the Bugzilla ticket with the proposal, listing several options (including hint, error message, switch, &c) ? I will then post the link here. Or perhap someone else wants to do it, too?

huh, i'm somewhat confused that my current nick isn't registered to me. it's what I used to register here, and my client should identify with nickserv on connection. will have to debug that

ant-x: of course i can wait, no problem

I'll be on vacation for a week starting sunday

Grabunhold_, You registered nick is Grabunhold, without the ending underscore.

A vacation, meaning fore time for FreeBSD :-))

I suggest that you either use your original nick, or registed this one as well via /msg nickserv group

Indeed: I can become ant-z, although it is not a registered nick. You cannot send me a memo via ant-z .

ant-x: indeed something is wrong with my quassel core (advanced irc bouncer if you want to call it that), it's blocking my original nickname with a second connection. i will have to look into that

Hello all, is there anyone into freebsd and security? I have a one week paid job please to propose - thank you

Juliaaa, did someone reach out to you?

hello CrtxReavr, someone did yes

Juliaaa, I don't understand what you are talking about. If somewhat asked to find him in this group, you already have his nick and can contact him directly by private message or MemoServ.

with find, does {} contain the full path of the found file or just the file name ?

just try with echo?

last1: the path relative to the root directory provided to the find command. e.g. if you do `find .` then {} might be ./foo/bar/file.txt

I tried with -exec ls -la {} \; and it shows the full path

but -exec diff {} ../other_dir/{} \; only uses the filename in the ../other_dir/

does it act differently when it's part of a manually given path ?

i am not aware of any way to invoke find without a manually-provided path, can you show an example?

find api/ -type f -exec diff {} ../gtech/api/{} \;

errors out with: diff: ../gtech/api/Get.php: No such file or directory

then the root is `api/` so your filenames will be e.g. `api/foo/bar.txt`

with your diff example, you'd need to have `api/foo/bar.txt` and `../other_dir/api/foo/bar.txt`

yes..I do. The actual file is: api/vendor/elasticsearch/elasticsearch/src/Elasticsearch/Endpoints/Cluster/Settings/Get.php

but it somehow removes that path and just tries Get.php in the path that I gave it!

can you show a paste with the complete actual command you're running, the error it produces, and the result of 'ls -ld' on both the files you're concerned with?

sure, one moment

lw: oh holy shit you're back

kevans: uh i guess? i come and go, much like haemorrhoids

i responded to one of your PRs within a day or so then you disappeared

ah, this one: bugs.freebsd.org/bugzilla/show_bug.cgi?id=279850

lw: nvm, thank you. pebkac

kevans: oh sorry, i was meaning to look at it but i've been doing work stuff which means i'm on Windows

i was planning to do a new 15.0 build this week though so i can add that patch on my local branch and see if it fixes the problem if it's still helpful

last1, In find {} is replaced by the file path. The use case you are probably wanting is -execdir instead of -exec and in that case find changes directory first meaning that the path is always the short relative path which will work to add on an explicit path. Try: find api/ -type f -execdir diff -u {} ../gtech/api/{} \;

lw: yes please, thanks

ah wait, just saw your message

I was circling back to prove I'm not crazy lol

now it doesn't even print the file names anymore

is /usr/local/gtech a symlink?

no it's not

you might start with -execdir echo diff blah to see what it's doing before you start running it

let's step back a bit: anyone knows a better way to diff files in two directories with similar structure ?

diff -r

diff -r api ../gtech/api

I wanted to exclude the vendor dir and some other files, that's why I was using find

--exclude pattern

last1: `diff -x` might be useful?

let me try with diff, I got a bit carried away trying to make find work

it seems trivial until it wasn't

*seemed

seems to me that the api directory is a symlink

hmm, not sure from those pastes though

the exclude patterns for both diff and find have always eluded me, there's something special about them

how can I exclude api/vendor from diff ?

I tried with */api/vendor/* , all kinds of combinations, no luck

ah, this worked: diff -r -x "*vendor*" api ../gtech2/api

heh, didn't initially notice the gtech vs gtech2

well, surely i must have. anyway, glad you have it working..

yeah, was trying to salvage some code that wasn't in git

So, I've run into a problem with newly upgraded jails giving me errors from cron about adjkerntz, saying operation not permitted, and I can't find anything to resolve it.

xa0z: i don't think jails have ever allowed adjkerntz, except perhaps with the (very) recent 15.0 change that added a permission to let jails set/slew time. are you trying to run ntpdate/ntpd in a jail?

I was working on a patch for a bit to add essentially a time namespace to jails

should i disable procfs

for security?

kevans: why?

doesn't the host kernel always know the correct UTC time, i'm curious about the use case for a jail having the wrong time

and the toor user

lw: in my case, freebsd-update-server wanted to set the time between two builds to suss out differences that are just version stamps

i really wanted to run it without screwing up my system time

huh that sounds evil, use pkgbase :-)

sure, that's what I wanted to say, too :-)

I wasn't trying to use it for my own purposes

lw: No, ntpd and ntpdate is running on the host.

Is this typical for `freebsd-update IDS`? 0x0.st/Xpy-.log

lw: however, I just checked /etc/crontab and saw it's listed at the bottom...