Looks good (not run tested).

Approved.

Seems sane enough. It's not something we use today, and I've verified that run_rc_command should do the right thing w/o side effects (although I'd think that the -z rc_arg test should be higher in that function to avoid pid file name eval, etc).

Approved.

Thank you all for feedback! :)

• Add UPDATING entry
• Fix typos in rc.subr.8 and do some extra wordsmithing there

I'm sure it adds appreciable speedup in some cases, but I can't see us fixing support and keeping it working. Best to stop pretending and focus on lower hanging fruit.

In D47264#1078101, @0mp wrote:

I've got some reports from the NetBSD community that setting rc_fast_and_loose on NetBSD booting on vax simh makes rc finish in 109 seconds instead of 183 seconds (https://mastodon.sdf.org/@mrgtwentythree/113364676304360235).

At the same time, brooks@ mentioned in Bugzilla (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282255#c4) that the benefits of rc_fast_and_loose are probably negligible.

I've got some reports from the NetBSD community that setting rc_fast_and_loose on NetBSD booting on vax simh makes rc finish in 109 seconds instead of 183 seconds (https://mastodon.sdf.org/@mrgtwentythree/113364676304360235).

Approved, plus a minor nit.

In D47264#1077729, @markj wrote:

Approved.

This probably deserves an entry in UPDATING as well as the relnotes tag, since it breaks backward compatibility and applies to those who track main as well as release users.

This probably deserves an entry in UPDATING as well as the relnotes tag, since it breaks backward compatibility and applies to those who track main as well as release users.

Update docs and remove an unused boottrace function

Thanks!

Approved.

I'll set MFC to 2 weeks so that it does not land in 14.2.

Set exit status by calling exit in a subshell.

I opened a PR for investigating the rc_fast_and_loose support: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282255

Check all invocations.

In D46862#1076197, @gshapiro wrote:

This is an improvement over the current functionality, but I think we would want all invocations to be checked. I wonder if it would be better to separate these into separate rc scripts instead of using one for four possible different daemons. That shouldn't prevent this change from going forward while alternatives are formulated.

This is an improvement over the current functionality, but I think we would want all invocations to be checked. I wonder if it would be better to separate these into separate rc scripts instead of using one for four possible different daemons. That shouldn't prevent this change from going forward while alternatives are formulated.

LGTM. Only a minor nit: in the commit message there is a typo: "sendmai daemon ...".

Committed in https://cgit.freebsd.org/src/commit/?id=6fa42b91ca3f481912af98c4d49c44507eb1b8e1

Thanks!

Approved.

Approved.

I think this patch is a fair workaround for the issues reported in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223132.

In D46924#1072191, @gshapiro wrote:

In D46924#1072046, @markj wrote:

What exactly is the effect? Does sendmail actually need the shutdown keyword?

Yes, to ensure a clean shutdown of active SMTP connections (and writing any in memory queue files).

Approved.

In D46924#1072046, @markj wrote:

What exactly is the effect? Does sendmail actually need the shutdown keyword?

LGTM, approved.

This seems fine to me. Looks like it's been broken for a rather long time.

And the features got documented in 81b9905234e34a778dd524385279c2a807d83308...

This is a stopgap. A proper fix would require a rewrite of this service script and possibly a split of the different functionalities of this script into separate files.

A similar patch was committed to the tree: https://reviews.freebsd.org/D38292

In principle this only changes the user side setup (rc.conf), not the ports side. There is no direct ports consumer of this feature and it tries to hook into all services in order to automate configuration changes when service commands are dispatched.

In my work for the automatic service jails (committed last week), I stumbled upon cases (in the base system) where some kind of functions were used to setup variables before starting the actual service, which was not necessary. When the automatic service jail is enabled for such a service, some of this stuff was run outside the service jail and didn't had the desired effect. After changing those scripts to not setup variables like that, it worked.

In D36259#1035544, @franco_opnsense.org wrote:

This won't merge, I'm talking to @imp at https://github.com/freebsd/freebsd-src/pull/1258

Yes I just need to wrap up testing for the updated GH PR

Oh and I was going to try merge it :P
So we can close this review?

This won't merge, I'm talking to @imp at https://github.com/freebsd/freebsd-src/pull/1258

Was committed (tag was Differential not Differential Revision so it did not auto-close).

@0mp if you put just the short version of the review (D38344) Phab will show if its closed or still open. With that change committed there is presumably no reason for this change any longer?

No takers? This has been in a half-working state in FreeBSD 14 for quite some time. :/