00:00:24 And completely unambiguous: date "+%F %T %z" 03:35:29 ISO 8601 has the nice property that an alphabetic sort will sort dates in increasing order 04:07:40 yes, my idea of a perfect date is YYYY-MM-DD 04:17:58 it's a good 1 for sure 05:45:12 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 05:45:12 that program see the free space .  What might I do ? 06:50:39 Gone already... I'd have recommended to them to just get another HDD, it makes things so much easier 10:16:54 Grabunhold_, any luck yet? If not, try debuggin with the very minimal script from here: . 10:17:43 ant-x: i went back to thinking about it just one moment ago :D 10:18:29 That is synchronicity! 10:19:56 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. 10:21:56 And of course you have to add the shutdown keyword. 10:23:05 hmmm, it can't be so hard to get the "normal" script working can it? 10:23:05 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 10:23:43 cause the first line in that script says "log invocation and arguments into a file", but that doesn't happen for shutdown 10:23:53 Grabunhold_, In my experience, the first time, anything can be as hard as you can imagine, and then some :-) 10:24:38 Grabunhold_, Yes, right. I am not a native speaker either. 10:24:44 * ant-x shakes hands with Grabunhold_ 10:26:27 rc.shutdown is a script, right? If it is, you can test your service by invoking it manually, according to . 10:27:10 The idea is to try emulate what the OS does and hopefully to reproduce the error. 10:27:36 * invoked . 10:27:57 here is the current version by the way: https://pastebin.com/pqZKJUU5 10:30:29 ^ Are you sure PATH= is sufficient, and not export PATH= ? 10:31:07 yes, the only reason why that's there is that my script start subprocesses via /usr/local/bin 10:31:21 i got a command not found error, added that line, and they went away 10:31:24 Is it inherited without export? 10:31:36 I see. 10:31:48 it seems so. not sure why it was even necessary in the first place 10:31:58 So -- try invoking rc.shutdown as per RC(8) . 10:32:06 i wanted to investigate that further, but getting shutdown to work is priority #1 10:34:20 ^ 10:35:46 hmmmmmmmmmmmmmmmm, that manpage says that rc.shutdown should be at /etc/rc.shutdown, no? 10:36:02 because i have nothing at /etc/rc.shutdown 10:36:13 maybe we're on to something here 10:36:22 Grabunhold_, try to find / it. 10:37:05 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. 10:37:11 oh, it -is- there. i missed it somehow 10:37:13 stupid 10:37:16 * does /not/ actually say... 10:37:30 Then you can add some debug output in there, too 10:37:53 hehe, good thing i have a test machine just for debugging this :D 10:38:16 Which with luck will let you know why your script is not invoked. 10:39:30 Well, a simple backup copy of a file you change seems enough. I broke my system yesterday and regretted not having made a backup. 10:39:51 do you know about bectl? 10:39:57 No. 10:40:29 well, it is great for hacks like this. but it needs zfs, iirc you're on UFS? 10:40:55 Grabunhold_, Yes, a old laptop with 4GB RAM. They say ZFS is heavy, needs more memory. 10:42:43 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 10:43:37 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. 10:44:15 Grabunhold_, Why? With a lightweight wm it should be good. 10:44:37 ant-x: why zfs? because you get bectl, for example :D 10:44:52 i've inserted the following line just below line 100 in /etc/rc.shutdown: 10:44:52 echo "running faststop for $_rc_elem" >> /var/log/rc_shutdown_debug 10:44:55 ...sicne rc.shutdown itself accepts an argument, I wonder what is the purpose of rc_shutdown (with underscore). 10:45:28 reboot commencing... 10:45:32 Wait! 10:45:42 too late :D 10:45:57 We need more liberalism, some log before that loop, to see which files have been found. 10:46:29 Also, instead of rebooting, I /do/ suggest invoking rc.shutdown by hand -- will save time. 10:46:42 i wasn't sure what state the system would end up in 10:46:49 i'm accessing it via ssh 10:47:05 so i went for the full reboot 10:47:06 Oh... 10:47:35 well i can walk over to the next room and connect a console should something go seriously wrong 10:47:38 We need to log the output of rcorder. 10:47:41 it's not that bad 10:47:45 i'm just lazy :D 10:48:31 interesting, no output at all 10:48:48 cat: /var/log/rc_shutdown_debug: No such file or directory 10:48:48 One must be lazy, to connect by SSH to a machine in an adjacent room :-) 10:49:13 ant-x: well, it's server-grade hardware and unpleasantly loud to keep in the same room as oneself 10:49:33 I say: log the result of `rcorder -k shutdown' which is supposed to select rc.d. files for shutdown. 10:50:00 I mean whatever rcorder call is there inside rc.shutdown. 10:51:01 also there is no gui on that machine, so i'd have to setup an irc cli client and whatnot... 10:51:53 I call that job a text quest, after a classic genre of couputer games, by Infocom &c. 10:52:38 okay, these seem to be the relevant lines: https://pastebin.com/PeAFHZS6 10:53:27 (I was disconnected) 10:53:40 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? 10:54:17 okay, these seem to be the relevant lines: https://pastebin.com/PeAFHZS6 10:54:21 in case you missed it 10:54:26 Grabunhold_, make sure to lot it onto the root fs, in case the other directory is not mounted. 10:55:01 Great -- it sends error output to /dev/null -- bad manners, no? 10:56:30 okay, so... `sh /etc/rc.shutdown`? 10:56:35 I wonder what the `debug' call does. 10:56:37 i', prepared to walk over there! :D 10:56:43 ant-x: yeah i was too @ debug call 10:57:00 tried to find where that is defined, but it doesn't seem to be a function local to that script 10:57:05 Well, I will take the responsibility, but with you luck... 10:58:02 Grabunhold_, could be sourced in. 10:58:32 Grabunhold_, I think you have to pass some argument to rc.shutdown. 10:59:04 now would you look at that! https://pastebin.com/DJBKkU8p 10:59:30 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. 11:00:05 It works, when run manually... 11:00:21 By the way, it is /much/ better to refer to the raw text: 11:01:42 let's get the machine into a normal state again 11:01:49 remove the logs produced so far 11:01:59 and see if we can reproduce that with a "normal" reboot 11:03:11 Grabunhold_, what would be the difference from the previous reboot? 11:07:51 interesting. again, no /rc_debug_log file and no calls to "faststop" or "stop" in /var/log/anlasser/debug_stop 11:08:21 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?) 11:10:25 Different arguments may be passed to it -- log them. 11:15:10 let's start the script with "echo $* >> /rc_shutdown_invocation" 11:15:58 Yes, in the very first line. 11:19:00 it's the first line after the shebang and comments, "reboot", "cat: /rc_shutdown_invocation: No such file or directory" 11:19:01 huh. 11:19:36 As if rc.shutdown was not called at all! 11:19:50 what's the problem 11:20:27 rtprio, cannot log the invocatio of rc.shutdown prior to reboot. 11:21:29 ^ 11:21:47 Looks like it is not invoked. 11:25:26 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? 11:25:28 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: https://pastebin.com/raw/pqZKJUU5 11:26:08 start / stop works fine, and running "sh /etc/rc.shutdown" works fine and leads to the correct log lines 11:26:39 but doing a real reboot or shutdown doesn't. no log lines, no nothing 11:26:44 and i'm not sure what's wrong 11:27:18 and you've already read https://docs.freebsd.org/en/articles/rc-scripting/ ? 11:27:22 ant-x: devd config is completly stock here 11:27:23 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. 11:28:07 rtprio, Yes, I went though it yesterday. The rc.d script is question is available online. 11:28:29 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" 11:29:17 "service anlasser stop" and "service anlasser faststop" work as well 11:29:21 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. 11:29:32 so I'm under the impression that my script is correct @ rtprio 11:29:47 it's just that it isn't invoked during shutdown 11:30:12 e.g.: devd -d | grep --line-buffered 'shutdown' >> /devd.log 11:30:36 Am I right that rc.shutdown is invoked by a devd rules? 11:30:54 ant-x: no i doubt that very much 11:31:07 rtprio, Hmmmm, then what invokes it? 11:31:20 Can we log the point of invocation? 11:31:55 Grabunhold_: what happens when you rc.shutdown now? the daemon process is killed letting the app end? 11:32:28 rtprio: you mean "sh /etc/rc.shutdown"? 11:32:44 yes 11:33:08 i just ran that, it properly stopped my script 11:33:26 ^ Which is why I wonder what calls rc.shutdown at reboot. 11:34:00 the anticipated "Tue Jul 23 13:32:49 CEST 2024: Anlasser Received faststop command" line also appeared in /var/log/anlasser/debug_stop 11:34:18 why faststop 11:34:35 because that's how rc.shutdown invokes the rc scripts it seems 11:35:01 rtprio, indeed: even according the rc.d scripting guide. 11:35:16 Grabunhold_: When you test rebooting, do you use shutdown -r or reboot? 11:35:18 see line 105 of /etc/rc.shutdown 11:35:24 vkarlsen: "reboot" 11:35:35 Grabunhold_: try shutdown -r 11:36:21 and 'service anlasser faststop' also shuts down your thing properly? 11:36:35 rtprio: yes it does 11:36:38 vkarlsen, Is `reboot' not supposed to shutdown rc.d scripts/deamons ? 11:37:03 ant-x: I'm not sure that it does 11:37:09 reboot/ shutdown -r is the same thing 11:37:13 rtprio: but even if it didn't, at least the "invoked with faststop" line should appear in /var/log/anlasser/debug_stop 11:37:35 see line 15 here: https://pastebin.com/pqZKJUU5 11:38:02 eh, "received faststop command" 11:38:05 vkarlsen: will try 11:39:13 ant-x: According to the manpage, it just flushes the fs cache, sends all processes a SIGTERM (and then SIGKILL) and restarts 11:39:34 Who calls rc.shutdown? The rc(8) program? If so, who calls rc(8)? 11:40:10 vkarlsen, I just read that, which is very strage. It makes reboot a dangerous command! 11:40:52 I thought that maybe rc(8) was called from the devd handler of the shutdown event... 11:40:55 ant-x: Furthermore, shutdown(8) has an option to execute halt or reboot instead of sending a signal to init 11:41:42 If my hunch is right, Grabunhold_'s script might be completely correct, it's just never told to shut down 11:42:27 vkarlsen: it seems you're right. "shutdown -r now" seems to have lead to the correct log lines appearing 11:43:17 i'll double-verify that 11:43:57 /rc_shutdown_invocation appeared as well, content is "reboot" 11:44:00 that wasn't there before 11:44:46 /rc_shutdown_debug is there now, too. and it contains (beside other lines) "running faststop for /usr/local/etc/rc.d/anlasser" 11:46:53 Whew! So, `reboot' /is/ a dangerous command, e.g. if you have a DB running? 11:47:16 Congratulations, Grabunhold_ . 11:47:16 depends... on how fast your processes handlie SiGTERM 11:47:41 I should prefer to alias or symlink reboot as shutdown -r . 11:47:58 ant-x: Yeah, this should be communicated more clearly, I think 11:48:20 e.g.: reboot and reboot --fast/unsave 11:48:27 *unsafe 11:48:30 how often are you shuting down anyhow 11:48:45 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 11:48:50 Often -- mine is not server, but a laptop. 11:49:09 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 11:49:18 i've been rebooting FreeBSD systems with "reboot" for __years__ now 11:49:21 Grabunhold_, systemd is hated/loved. But the traditional init system probably does the same. 11:49:27 i never knew i was holding it wrong 11:49:46 Not /necessarily/ wrong, but less gracefully, as it were... 11:49:51 ant-x: i came up on gentoo / OpenRC. "reboot" was perfectly "normal" there, too 11:49:56 So have I. 11:50:38 i strongly suspect there is no difference between "reboot" and "shutdown -r now" on a typical modern linux system 11:50:55 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. 11:52:11 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 11:52:31 The last sentences here mentioning reboot(8) should perhaps have a bit more teeth -- https://docs.freebsd.org/en/books/handbook/boot/#boot-shutdown 11:52:50 well, i wouldn't even have thought to look at these docs 11:53:06 i type "reboot", machine reboots 11:53:09 vkarlsen, the docs are one thing, the principle of least astonishment quite another, no less important. 11:53:19 That's it. 11:53:35 i didn't even suspect there would be a need for me to look at the docs 11:53:37 reboot should be `fastreboot'. 11:53:49 Not for `reboot', anyway. 11:56:00 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!@ 11:56:22 Very, very counter-intuitive and surprising. 11:56:29 Glad I learned it. 11:56:39 well, immediately reboot the system. that's what i want! :D 11:56:45 Took Grabunhold_ two days and your help :-) 11:57:12 No, you want it /now/ but less imemediately, to let the services shutdown gracefully :-) 11:57:16 ant-x: well, i wouldn't call my stumbling along "help" in any way :D 11:57:37 Grabunhold_, did not rtprio solve you problem just now/ 11:58:02 ant-x: it was vkarlsen who suggested "shutdown -r now" 11:58:24 Oh, then him. I thank him for the explanaiton. 12:01:11 ant-x: i see 2 problems with this situation. I wouldn't 12:01:11 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. 12:01:11 b) have interpreted "immeadiately" to mean "bypassing the proper procedures". reading that sentence without further knowledge, i would simply assume it means "without delay" 12:02:13 Do you mean a) have /not/ thought and b) have /not/ ingerpreted ? That about describes my experience, too. 12:02:26 Oh, yes I see. 12:04:06 ant-x: eh, i meant the "i wouldn't" to go in front of these two options 12:04:15 i guess i could write more clearly myself :D 12:05:33 oof. i could have spent days and days debugging my rc script, questioning everything in there and only getting more confused following red herrings 12:07:37 We can propose an improved doc, or perhaps even better semantics for reboot, which by default should be equivalent to shutdown -r how. 12:07:40 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? 12:07:45 ^ on bugzilla. 12:07:50 Yes 12:09:07 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 12:10:35 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. 12:10:35 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. 12:11:14 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 12:11:41 i'm personally mildly against it but not to the point i really care either way 12:11:59 lw: yeah, i just spent 2 days trying to understand why my (first-time) rc-script wouldn't execute it's stop-procedure 12:12:43 being new to writing rc scripts, i thought of course it must be my fault 12:12:52 well, you may get your wish as iirc most people were in support of this change 12:12:59 and somehow it was, but not because my script was wrong but because i simply used "reboot" 12:15:39 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 12:16:13 lw: What are your objections? 12:17:07 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 12:17:07 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) 12:17:32 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 12:18:20 lw: maybe "reboot" could simply print something to stdout along the lines of "emergency reboot; bypassing proper shutdown procedures" or something 12:18:43 that would keep the functionality where it is, but immeadiately give people like me the right hint 12:19:07 lw: I agree 12:20:04 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 12:21:23 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 12:21:51 i'm okay to accept that lowest-effort solution for most users is to just make reboot behave like Linux 12:22:00 i'm sure that won't be difficult to get used to 12:22:27 at least we're not on SVR4 where you have to use "shutdown -i6 -g0", the most opaque command ever 12:23:04 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 12:23:16 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 12:23:29 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) 12:23:49 dstolfa: i look, stand by 12:28:15 dstolfa: i think i'm thinking of this thread: https://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) 12:37:00 lw: thanks 12:38:42 does it make sense to revive a thread that old? i have zero experience with mailing lists 12:39:03 probably not, but you could mail imp⊙fo with your views and/or to ask what became of that idea 12:39:09 he is quite friendly 12:40:24 he is also pretty busy so it's possible he just forgot / never got around to it 12:44:05 will do :) 13:21:25 scoobybejesus, re: reboot == shutdow -r . I agree. Perhaps shutdown -r now. 13:23:34 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. 13:24:56 Is there a bugzilla ticket about it, too? 13:25:34 Grabunhold_, mailing lists are great, especially when used with a good e-mail client and Gmane. 13:25:44 well it certainly shouldn't be a GNU long option, but using the existing fastboot(8) for that should be fine 13:27:30 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. 13:28:42 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. 13:29:43 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? 13:29:45 also similar to how we moved to make autoboot the default, even though that might confuse admins used to the older behaviour 13:30:31 I think most users will not actually notice the difference between boot and shutdown -r now. 13:31:26 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@ . 13:32:20 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 13:32:22 ant-x: deal! 13:32:41 dstolfa: do you think people run Linux provisioning scripts unmodified on FreeBSD? that sounds error-prone 13:32:53 lw: it would not surprise me tbh 13:32:58 dstolfa: i use Ansible to configure FreeBSD hosts, I wonder what Ansible is doing when I'm using the "reboot" module 13:33:29 Grabunhold_, please, learn the usage of /msg MemoServ help . It will let us stay in touch when not online. 13:34:05 ant-x: i actually read your last memo :) 13:34:22 Great, and you send them, too. 13:35:48 Grabunhold_, you are registered here at #libera, but your current nick is not registered to you. You can do so by /msg NickServ group . 13:36:09 It will let me send memos to this nick. 13:37:49 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? 13:38:49 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 13:39:08 ant-x: of course i can wait, no problem 13:39:28 I'll be on vacation for a week starting sunday 13:49:30 Grabunhold_, You registered nick is Grabunhold, without the ending underscore. 13:49:49 A vacation, meaning fore time for FreeBSD :-)) 13:50:33 I suggest that you either use your original nick, or registed this one as well via /msg nickserv group 13:51:42 Indeed: I can become ant-z, although it is not a registered nick. You cannot send me a memo via ant-z . 14:09:20 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 15:20:43 Hello all, is there anyone into freebsd and security? I have a one week paid job please to propose - thank you 15:41:41 Juliaaa, did someone reach out to you? 15:55:25 hello CrtxReavr, someone did yes 16:34:21 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. 16:45:30 with find, does {} contain the full path of the found file or just the file name ? 16:45:53 just try with echo? 16:45:58 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 16:46:17 I tried with -exec ls -la {} \; and it shows the full path 16:46:37 but -exec diff {} ../other_dir/{} \; only uses the filename in the ../other_dir/ 16:47:01 does it act differently when it's part of a manually given path ? 16:47:16 i am not aware of any way to invoke find without a manually-provided path, can you show an example? 16:48:09 find api/ -type f -exec diff {} ../gtech/api/{} \; 16:48:33 errors out with: diff: ../gtech/api/Get.php: No such file or directory 16:48:50 then the root is `api/` so your filenames will be e.g. `api/foo/bar.txt` 16:49:25 with your diff example, you'd need to have `api/foo/bar.txt` and `../other_dir/api/foo/bar.txt` 16:49:38 yes..I do. The actual file is: api/vendor/elasticsearch/elasticsearch/src/Elasticsearch/Endpoints/Cluster/Settings/Get.php 16:50:01 but it somehow removes that path and just tries Get.php in the path that I gave it! 16:51:22 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? 16:51:31 sure, one moment 16:56:13 lw: oh holy shit you're back 16:56:35 kevans: uh i guess? i come and go, much like haemorrhoids 16:57:04 i responded to one of your PRs within a day or so then you disappeared 16:57:09 * kevans tries to remember where 16:57:37 ah, this one: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279850 16:59:35 lw: nvm, thank you. pebkac 16:59:51 kevans: oh sorry, i was meaning to look at it but i've been doing work stuff which means i'm on Windows 17:00:22 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 17:03:30 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/{} \; 17:04:21 lw: yes please, thanks 17:07:45 https://pastebin.com/Erx7rf6A 17:07:59 ah wait, just saw your message 17:08:07 I was circling back to prove I'm not crazy lol 17:09:18 https://pastebin.com/w45ZF0GC 17:09:30 now it doesn't even print the file names anymore 17:10:15 is /usr/local/gtech a symlink? 17:10:19 no it's not 17:11:18 https://pastebin.com/MSFaaag9 17:11:31 you might start with -execdir echo diff blah to see what it's doing before you start running it 17:11:58 let's step back a bit: anyone knows a better way to diff files in two directories with similar structure ? 17:12:03 diff -r 17:12:19 diff -r api ../gtech/api 17:13:03 I wanted to exclude the vendor dir and some other files, that's why I was using find 17:13:39 --exclude pattern 17:13:46 last1: `diff -x` might be useful? 17:16:03 let me try with diff, I got a bit carried away trying to make find work 17:16:07 it seems trivial until it wasn't 17:16:10 *seemed 17:17:24 seems to me that the api directory is a symlink 17:18:08 hmm, not sure from those pastes though 17:18:32 https://pastebin.com/5qr5GCVv 17:19:57 the exclude patterns for both diff and find have always eluded me, there's something special about them 17:21:06 https://pastebin.com/06XvrYX9 17:21:24 how can I exclude api/vendor from diff ? 17:23:25 I tried with */api/vendor/* , all kinds of combinations, no luck 17:24:01 ah, this worked: diff -r -x "*vendor*" api ../gtech2/api 17:27:08 heh, didn't initially notice the gtech vs gtech2 17:28:24 well, surely i must have. anyway, glad you have it working.. 17:50:18 yeah, was trying to salvage some code that wasn't in git 18:26:00 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. 18:52:52 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? 19:11:49 I was working on a patch for a bit to add essentially a time namespace to jails 19:17:07 should i disable procfs 19:17:09 for security? 19:18:52 kevans: why? 19:19:26 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 19:19:30 and the toor user 19:35:14 lw: in my case, freebsd-update-server wanted to set the time between two builds to suss out differences that are just version stamps 19:35:31 i really wanted to run it without screwing up my system time 19:35:46 huh that sounds evil, use pkgbase :-) 19:36:02 sure, that's what I wanted to say, too :-) 19:36:09 I wasn't trying to use it for my own purposes 21:27:34 lw: No, ntpd and ntpdate is running on the host. 21:34:19 Is this typical for `freebsd-update IDS`? https://0x0.st/Xpy-.log 21:35:04 lw: however, I just checked /etc/crontab and saw it's listed at the bottom...