Re: svn commit: r331880 - stable/11/etc

[Rodney W. Grimes]

> On 04/10/18 04:28, Kyle Evans wrote:
> > On Mon, Apr 9, 2018 at 11:59 AM, Warner Losh  wrote:
> >>
> >>
> >> On Mon, Apr 9, 2018 at 10:09 AM, Kyle Evans  wrote:
> >>>
> >>> Right- so, back out this MFC (and the subsequent FreeBSD_version bump)
> >>> and fix the ports to do the right thing for 12.x while that's still
> >>> not a technically supported branch?
> >>
> >>
> >> Don't back out the version bump. Other things may be riding along on it 
> >> 'for
> >> free'. Better to bump it again when you unMFC (if it's been more than a few
> >> days since we've had one), and then yet-again when a fixed MFC happens.
> >> Unless there's something you can ride along on for free :)
> >>
> >> Otherwise, that's a great plan.
> > 
> > Ok, I think the result of this thread and discussion with 0mp is the
> > following set of actions:
> > 
> > 1.) One (1) commit to stable/11 to revert the MFC and bump
> > FreeBSD_Version again for the removal
> > 2.) One (1) commit to doc to document the new FreeBSD_Version
> > 3.) Fixing ports to use the "new" behavior on 12, both the
> > yet-to-be-patched ports and the ports that had already been patched
> > under the assumption that it would still land first in 11.1-stable
> > 4.) Documenting the original commit?
> > 
> > The hard part of point #3 has already been done by 0mp, who has
> > submitted patches for all of the ports using this behavior. His
> > patches will just need a bump of the version they're testing to the
> > 12.x FreeBSD_Version and a fix-up on the patches that already landed.
> > 
> > For point #4, this seems like the type of breakage we should be
> > documenting in release notes or something for the eventual upgrading
> > of systems to 12.0. All usage of _limits stuff in custom rc scripts
> > need to be audited, and all rc.conf(5)'s need to be scrubbed for
> > ${name}_limits usage that doesn't make sense with the new context. I'm
> > not sure what the most appropriate action here is, or what we should
> > do this far ahead of time for such a thing.
> > 
> > If this sounds like a good path forward, I'll execute #1 and #2 in the
> > morning (CST, so ~11 hours from this e-mail being sent).
> > 
> 
> This still doesn't fix the issue of some early start up scripts 
> depending on stuff that's not available yet, when for instance /usr is 
> on a separate FS (which was the normal way to set up a system way back 
> when).

The words "way back when" is become less needed.  With the advent of
hypervisors, 100GbE and NVMe over fabric the idea of sharing /usr across
a whole cluster of VM's is become more desireable.   1 copy of /usr
shared from a memory file system via fast network technologies has
advantages.

> This issue was first noticed more than 2 years ago, so someone did 
> notice the breakage.  It just hasn't been fixed for an entire release cycle.
> Regards

One thing that is not helping the bit rot is that some reworking of
/etc/rc* stuff has caused it to now ignore most errors from my things,
and that just causes a message on the console that no one is reading
so when something gets broke it a) doesnt get noticed cause thier
machine just boots, and b) doesnt get fixed cause few are actually
effected by the caused error.

If you are willing to help me weed out the failure modes, I am willing
to try and mount an effort, along with others, to try and get us back
on track.

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r331880 - stable/11/etc

[Kyle Evans]

On Mon, Apr 9, 2018 at 11:22 PM, Rodney W. Grimes
 wrote:
> [ Charset UTF-8 unsupported, converting... ]
>> On Mon, Apr 9, 2018 at 11:59 AM, Warner Losh  wrote:
>> >
>> >
>> > On Mon, Apr 9, 2018 at 10:09 AM, Kyle Evans  wrote:
>> >>
>> >> Right- so, back out this MFC (and the subsequent FreeBSD_version bump)
>> >> and fix the ports to do the right thing for 12.x while that's still
>> >> not a technically supported branch?
>> >
>> >
>> > Don't back out the version bump. Other things may be riding along on it 
>> > 'for
>> > free'. Better to bump it again when you unMFC (if it's been more than a few
>> > days since we've had one), and then yet-again when a fixed MFC happens.
>> > Unless there's something you can ride along on for free :)
>> >
>> > Otherwise, that's a great plan.
>>
>> Ok, I think the result of this thread and discussion with 0mp is the
>> following set of actions:
>>
>> 1.) One (1) commit to stable/11 to revert the MFC and bump
>> FreeBSD_Version again for the removal
>> 2.) One (1) commit to doc to document the new FreeBSD_Version
>> 3.) Fixing ports to use the "new" behavior on 12, both the
>> yet-to-be-patched ports and the ports that had already been patched
>> under the assumption that it would still land first in 11.1-stable
>> 4.) Documenting the original commit?
>>
>> The hard part of point #3 has already been done by 0mp, who has
>> submitted patches for all of the ports using this behavior. His
>> patches will just need a bump of the version they're testing to the
>> 12.x FreeBSD_Version and a fix-up on the patches that already landed.
>>
>> For point #4, this seems like the type of breakage we should be
>> documenting in release notes or something for the eventual upgrading
>> of systems to 12.0. All usage of _limits stuff in custom rc scripts
>> need to be audited, and all rc.conf(5)'s need to be scrubbed for
>> ${name}_limits usage that doesn't make sense with the new context. I'm
>> not sure what the most appropriate action here is, or what we should
>> do this far ahead of time for such a thing.
>
> We do need a way to stack little notes that need to make it into
> the release notes, even if there is no single commit they are related
> to, or in this case we find out later that a change had wider
> impacts and needs to have a note added.  Maybe gjb@ has a place we
> can just commit to that gets collected for the release?
>
>> If this sounds like a good path forward, I'll execute #1 and #2 in the
>> morning (CST, so ~11 hours from this e-mail being sent).
>
> I am on board with this much of this plan.
>
>
> What about cy@ changes to the ddb and other startup scripts?
>

Right- I was mostly concerned with fixing the fallout from this
particular commit. I think that merits its own discussion in a
separate thread or in the early referenced PR, but I'm tempted to go
ahead and commit Cy's ddb patch to start while we assess the other
damage.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r331880 - stable/11/etc

[Alexey Dokuchaev]

On Tue, Apr 10, 2018 at 01:29:19AM +0200, Oliver Pinter wrote:
> On Monday, April 9, 2018, Warner Losh  wrote:
> > On Mon, Apr 9, 2018 at 10:09 AM, Kyle Evans  wrote:
> > > Right- so, back out this MFC (and the subsequent FreeBSD_version bump)
> > > and fix the ports to do the right thing for 12.x while that's still
> > > not a technically supported branch?
> >
> > Don't back out the version bump. Other things may be riding along on it
> > 'for free'. Better to bump it again when you unMFC (if it's been more than
> > a few days since we've had one), and then yet-again when a fixed MFC
> > happens. Unless there's something you can ride along on for free :)
> >
> > Otherwise, that's a great plan.
> 
> What's about "direction Z"? Like moving find to /bin and do a compatibility
> symlink for them from /usr/bin?

That smells fishy.  Reminds me of GNU/Linux where I typically have to parse
through gazillion of compatibility symlinks before stumbling upon 30-byte
shim saying "implemented in systemd now". :-(

./danfe
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r331880 - stable/11/etc

[Niclas Zeising]

On 04/10/18 04:28, Kyle Evans wrote:

On Mon, Apr 9, 2018 at 11:59 AM, Warner Losh  wrote:



On Mon, Apr 9, 2018 at 10:09 AM, Kyle Evans  wrote:


Right- so, back out this MFC (and the subsequent FreeBSD_version bump)
and fix the ports to do the right thing for 12.x while that's still
not a technically supported branch?



Don't back out the version bump. Other things may be riding along on it 'for
free'. Better to bump it again when you unMFC (if it's been more than a few
days since we've had one), and then yet-again when a fixed MFC happens.
Unless there's something you can ride along on for free :)

Otherwise, that's a great plan.


Ok, I think the result of this thread and discussion with 0mp is the
following set of actions:

1.) One (1) commit to stable/11 to revert the MFC and bump
FreeBSD_Version again for the removal
2.) One (1) commit to doc to document the new FreeBSD_Version
3.) Fixing ports to use the "new" behavior on 12, both the
yet-to-be-patched ports and the ports that had already been patched
under the assumption that it would still land first in 11.1-stable
4.) Documenting the original commit?

The hard part of point #3 has already been done by 0mp, who has
submitted patches for all of the ports using this behavior. His
patches will just need a bump of the version they're testing to the
12.x FreeBSD_Version and a fix-up on the patches that already landed.

For point #4, this seems like the type of breakage we should be
documenting in release notes or something for the eventual upgrading
of systems to 12.0. All usage of _limits stuff in custom rc scripts
need to be audited, and all rc.conf(5)'s need to be scrubbed for
${name}_limits usage that doesn't make sense with the new context. I'm
not sure what the most appropriate action here is, or what we should
do this far ahead of time for such a thing.

If this sounds like a good path forward, I'll execute #1 and #2 in the
morning (CST, so ~11 hours from this e-mail being sent).



This still doesn't fix the issue of some early start up scripts 
depending on stuff that's not available yet, when for instance /usr is 
on a separate FS (which was the normal way to set up a system way back 
when).
This issue was first noticed more than 2 years ago, so someone did 
notice the breakage.  It just hasn't been fixed for an entire release cycle.

Regards
--
Niclas
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r331880 - stable/11/etc

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> On Mon, Apr 9, 2018 at 11:59 AM, Warner Losh  wrote:
> >
> >
> > On Mon, Apr 9, 2018 at 10:09 AM, Kyle Evans  wrote:
> >>
> >> Right- so, back out this MFC (and the subsequent FreeBSD_version bump)
> >> and fix the ports to do the right thing for 12.x while that's still
> >> not a technically supported branch?
> >
> >
> > Don't back out the version bump. Other things may be riding along on it 'for
> > free'. Better to bump it again when you unMFC (if it's been more than a few
> > days since we've had one), and then yet-again when a fixed MFC happens.
> > Unless there's something you can ride along on for free :)
> >
> > Otherwise, that's a great plan.
> 
> Ok, I think the result of this thread and discussion with 0mp is the
> following set of actions:
> 
> 1.) One (1) commit to stable/11 to revert the MFC and bump
> FreeBSD_Version again for the removal
> 2.) One (1) commit to doc to document the new FreeBSD_Version
> 3.) Fixing ports to use the "new" behavior on 12, both the
> yet-to-be-patched ports and the ports that had already been patched
> under the assumption that it would still land first in 11.1-stable
> 4.) Documenting the original commit?
> 
> The hard part of point #3 has already been done by 0mp, who has
> submitted patches for all of the ports using this behavior. His
> patches will just need a bump of the version they're testing to the
> 12.x FreeBSD_Version and a fix-up on the patches that already landed.
> 
> For point #4, this seems like the type of breakage we should be
> documenting in release notes or something for the eventual upgrading
> of systems to 12.0. All usage of _limits stuff in custom rc scripts
> need to be audited, and all rc.conf(5)'s need to be scrubbed for
> ${name}_limits usage that doesn't make sense with the new context. I'm
> not sure what the most appropriate action here is, or what we should
> do this far ahead of time for such a thing.

We do need a way to stack little notes that need to make it into
the release notes, even if there is no single commit they are related
to, or in this case we find out later that a change had wider
impacts and needs to have a note added.  Maybe gjb@ has a place we
can just commit to that gets collected for the release?

> If this sounds like a good path forward, I'll execute #1 and #2 in the
> morning (CST, so ~11 hours from this e-mail being sent).

I am on board with this much of this plan.


What about cy@ changes to the ddb and other startup scripts?

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r331880 - stable/11/etc

[Kyle Evans]

On Mon, Apr 9, 2018 at 11:59 AM, Warner Losh  wrote:
>
>
> On Mon, Apr 9, 2018 at 10:09 AM, Kyle Evans  wrote:
>>
>> Right- so, back out this MFC (and the subsequent FreeBSD_version bump)
>> and fix the ports to do the right thing for 12.x while that's still
>> not a technically supported branch?
>
>
> Don't back out the version bump. Other things may be riding along on it 'for
> free'. Better to bump it again when you unMFC (if it's been more than a few
> days since we've had one), and then yet-again when a fixed MFC happens.
> Unless there's something you can ride along on for free :)
>
> Otherwise, that's a great plan.

Ok, I think the result of this thread and discussion with 0mp is the
following set of actions:

1.) One (1) commit to stable/11 to revert the MFC and bump
FreeBSD_Version again for the removal
2.) One (1) commit to doc to document the new FreeBSD_Version
3.) Fixing ports to use the "new" behavior on 12, both the
yet-to-be-patched ports and the ports that had already been patched
under the assumption that it would still land first in 11.1-stable
4.) Documenting the original commit?

The hard part of point #3 has already been done by 0mp, who has
submitted patches for all of the ports using this behavior. His
patches will just need a bump of the version they're testing to the
12.x FreeBSD_Version and a fix-up on the patches that already landed.

For point #4, this seems like the type of breakage we should be
documenting in release notes or something for the eventual upgrading
of systems to 12.0. All usage of _limits stuff in custom rc scripts
need to be audited, and all rc.conf(5)'s need to be scrubbed for
${name}_limits usage that doesn't make sense with the new context. I'm
not sure what the most appropriate action here is, or what we should
do this far ahead of time for such a thing.

If this sounds like a good path forward, I'll execute #1 and #2 in the
morning (CST, so ~11 hours from this e-mail being sent).
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r331880 - stable/11/etc

[Oliver Pinter]

On Monday, April 9, 2018, Warner Losh  wrote:

> On Mon, Apr 9, 2018 at 10:09 AM, Kyle Evans  wrote:
>
> > Right- so, back out this MFC (and the subsequent FreeBSD_version bump)
> > and fix the ports to do the right thing for 12.x while that's still
> > not a technically supported branch?
>
>
> Don't back out the version bump. Other things may be riding along on it
> 'for free'. Better to bump it again when you unMFC (if it's been more than
> a few days since we've had one), and then yet-again when a fixed MFC
> happens. Unless there's something you can ride along on for free :)
>
> Otherwise, that's a great plan.


What's about "direction Z"? Like moving find to /bin and do a compatibility
symlink for them from /usr/bin?


>
> Warner
> ___
> svn-src-stable...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-stable-11
> To unsubscribe, send any mail to "
> svn-src-stable-11-unsubscr...@freebsd.org"
>
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r331880 - stable/11/etc

[Warner Losh]

On Mon, Apr 9, 2018 at 10:09 AM, Kyle Evans  wrote:

> Right- so, back out this MFC (and the subsequent FreeBSD_version bump)
> and fix the ports to do the right thing for 12.x while that's still
> not a technically supported branch?


Don't back out the version bump. Other things may be riding along on it
'for free'. Better to bump it again when you unMFC (if it's been more than
a few days since we've had one), and then yet-again when a fixed MFC
happens. Unless there's something you can ride along on for free :)

Otherwise, that's a great plan.

Warner
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r331880 - stable/11/etc

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> On Mon, Apr 9, 2018 at 10:52 AM, Rodney W. Grimes
>  wrote:
> >> On Mon, Apr 9, 2018 at 10:30 AM, Rodney W. Grimes
> >>  wrote:
> >> >> On Mon, Apr 9, 2018 at 10:14 AM, Rodney W. Grimes
> >> >>  wrote:
> >> >> >> On Mon, Apr 9, 2018 at 9:46 AM, Rodney W. Grimes
> >> >> >>  wrote:
> >> >> >> >> On 04/02/18 17:39, Rodney W. Grimes wrote:
> >> >> >> >> >> Author: kevans
> >> >> >> >> >> Date: Mon Apr  2 15:28:48 2018
> >> >> >> >> >> New Revision: 331880
> >> >> >> >> >> URL: https://svnweb.freebsd.org/changeset/base/331880
> >> >> >> >> >>
> >> >> >> >> >> Log:
> >> >> >> >> >>MFC r328331: Support configuring arbitrary limits(1) for 
> >> >> >> >> >> any rc.conf daemon
> >> >> >> >> >>
> >> >> >> >> >>Usage is ${name}_limits, and the argument is any flags 
> >> >> >> >> >> accepted by
> >> >> >> >> >>limits(1), such as `-n 100' (e.g. only allow 100 open 
> >> >> >> >> >> files).
> >> >> >> >> >>
> >> >> >> >> >> Modified:
> >> >> >> >> >>stable/11/etc/rc.subr
> >> >> >> >> >> Directory Properties:
> >> >> >> >> >>stable/11/   (props changed)
> >> >> >> >> >>
> >> >> >> >> >> Modified: stable/11/etc/rc.subr
> >> >> >> >> >> ==
> >> >> >> >> >> --- stable/11/etc/rc.subr  Mon Apr  2 15:07:41 2018
> >> >> >> >> >> (r331879)
> >> >> >> >> >> +++ stable/11/etc/rc.subr  Mon Apr  2 15:28:48 2018
> >> >> >> >> >> (r331880)
> >> >> >> >> >> @@ -773,6 +773,8 @@ check_startmsgs()
> >> >> >> >> >>   #
> >> >> >> >> >>   #${name}_login_class n   Login class to use, else 
> >> >> >> >> >> "daemon".
> >> >> >> >> >>   #
> >> >> >> >> >> +# ${name}_limits  n   limits(1) to apply to ${command}.
> >> >> >> >> >> +#
> >> >> >> >> >
> >> >> >> >> > Caution, limits(1) is in /usr/bin, this code can fail if used 
> >> >> >> >> > before
> >> >> >> >> > /usr is mounted.  (Ie, our rc.initdiskless) is probably broken 
> >> >> >> >> > by
> >> >> >> >> > this change if a call is made to limits.
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >> Sorry for jumping on this so late.  This is also an issue in 
> >> >> >> >> CURRENT,
> >> >> >> >> and has been since at least 2016.
> >> >> >> >
> >> >> >> > I was aware that it was an issue and why I made a comment about it
> >> >> >> > being MFC'ed.  Though I had forgot a bug report existed.
> >> >> >>
> >> >> >> I'm kind of surprised we haven't had more complaints about this- the
> >> >> >> original commit for this stuff landed before stable/11 was even
> >> >> >> branched, so it's been broken for all of 11.x's lifetime.
> >> >> >
> >> >> > History has taught me it takes a long time for this type of
> >> >> > breakage to usually surface in a noticable way.  Also I think
> >> >> > until you merged this last ${name}_limits thing it actually
> >> >> > didn't cause an issue, except for the few like me running
> >> >> > diskless systems and or seperate /usr.
> >> >>
> >> >> I don't see how this merge could possibly have been the cause of any
> >> >> claimed issues- like I said before, it didn't add any limits
> >> >> invocations, it added an arg to the limits invocation that already
> >> >> existed. You can see this pretty clearly from the diff, we didn't even
> >> >> change any conditions for limits to be invoked.
> >> >
> >> > limits_mysql="NO" is defined by the startup script for mysql,
> >> > that now causes /etc/rc to try and use that variable in a
> >> > different way.
> >> >
> >> > You added a variable, one that was already in use by some other
> >> > /etc/rc* related component.  Collision of differening uses is
> >> > causing errors.
> >> >
> >>
> >> Ah, apologies, I misread your previous e-mail and had interpreted it
> >> as you claiming again that this broke things for those of you "running
> >> diskless systems and or seperate /usr." -- this other breakage, these
> >> are things we can fix and aren't really large hurdles to climb over.
> >
> > Mostly true, other than the hurdle of that 0mp mentions in his
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227205
> > We need to remember that we cannot simply switch to
> > the new mechanism as it is only available in 12-CURRENT
> > and soon in 11-STABLE (and 11.2).
> >
> > I am not sure how to handle that with the users, it is a operational
> > interface change in how limits are done for these ports and probably
> > is going to break a lot of peoples systems if they try to update
> > from 11.1 to 11.2 because there /etc/rc.conf file is full of old
> > stuff that this new stuff is incompatible with.
> >
> > IMHO, it would be best to post pone this change to 12, as people
> > are more willing to suffer painful upgrades when going between
> > major versions.
> >
> 
> Right- so, back out this MFC (and the 

Re: svn commit: r331880 - stable/11/etc

[Kyle Evans]

On Mon, Apr 9, 2018 at 10:52 AM, Rodney W. Grimes
 wrote:
>> On Mon, Apr 9, 2018 at 10:30 AM, Rodney W. Grimes
>>  wrote:
>> >> On Mon, Apr 9, 2018 at 10:14 AM, Rodney W. Grimes
>> >>  wrote:
>> >> >> On Mon, Apr 9, 2018 at 9:46 AM, Rodney W. Grimes
>> >> >>  wrote:
>> >> >> >> On 04/02/18 17:39, Rodney W. Grimes wrote:
>> >> >> >> >> Author: kevans
>> >> >> >> >> Date: Mon Apr  2 15:28:48 2018
>> >> >> >> >> New Revision: 331880
>> >> >> >> >> URL: https://svnweb.freebsd.org/changeset/base/331880
>> >> >> >> >>
>> >> >> >> >> Log:
>> >> >> >> >>MFC r328331: Support configuring arbitrary limits(1) for any 
>> >> >> >> >> rc.conf daemon
>> >> >> >> >>
>> >> >> >> >>Usage is ${name}_limits, and the argument is any flags 
>> >> >> >> >> accepted by
>> >> >> >> >>limits(1), such as `-n 100' (e.g. only allow 100 open files).
>> >> >> >> >>
>> >> >> >> >> Modified:
>> >> >> >> >>stable/11/etc/rc.subr
>> >> >> >> >> Directory Properties:
>> >> >> >> >>stable/11/   (props changed)
>> >> >> >> >>
>> >> >> >> >> Modified: stable/11/etc/rc.subr
>> >> >> >> >> ==
>> >> >> >> >> --- stable/11/etc/rc.subr  Mon Apr  2 15:07:41 2018
>> >> >> >> >> (r331879)
>> >> >> >> >> +++ stable/11/etc/rc.subr  Mon Apr  2 15:28:48 2018
>> >> >> >> >> (r331880)
>> >> >> >> >> @@ -773,6 +773,8 @@ check_startmsgs()
>> >> >> >> >>   #
>> >> >> >> >>   #${name}_login_class n   Login class to use, else 
>> >> >> >> >> "daemon".
>> >> >> >> >>   #
>> >> >> >> >> +# ${name}_limits  n   limits(1) to apply to ${command}.
>> >> >> >> >> +#
>> >> >> >> >
>> >> >> >> > Caution, limits(1) is in /usr/bin, this code can fail if used 
>> >> >> >> > before
>> >> >> >> > /usr is mounted.  (Ie, our rc.initdiskless) is probably broken by
>> >> >> >> > this change if a call is made to limits.
>> >> >> >> >
>> >> >> >> >
>> >> >> >>
>> >> >> >> Sorry for jumping on this so late.  This is also an issue in 
>> >> >> >> CURRENT,
>> >> >> >> and has been since at least 2016.
>> >> >> >
>> >> >> > I was aware that it was an issue and why I made a comment about it
>> >> >> > being MFC'ed.  Though I had forgot a bug report existed.
>> >> >>
>> >> >> I'm kind of surprised we haven't had more complaints about this- the
>> >> >> original commit for this stuff landed before stable/11 was even
>> >> >> branched, so it's been broken for all of 11.x's lifetime.
>> >> >
>> >> > History has taught me it takes a long time for this type of
>> >> > breakage to usually surface in a noticable way.  Also I think
>> >> > until you merged this last ${name}_limits thing it actually
>> >> > didn't cause an issue, except for the few like me running
>> >> > diskless systems and or seperate /usr.
>> >>
>> >> I don't see how this merge could possibly have been the cause of any
>> >> claimed issues- like I said before, it didn't add any limits
>> >> invocations, it added an arg to the limits invocation that already
>> >> existed. You can see this pretty clearly from the diff, we didn't even
>> >> change any conditions for limits to be invoked.
>> >
>> > limits_mysql="NO" is defined by the startup script for mysql,
>> > that now causes /etc/rc to try and use that variable in a
>> > different way.
>> >
>> > You added a variable, one that was already in use by some other
>> > /etc/rc* related component.  Collision of differening uses is
>> > causing errors.
>> >
>>
>> Ah, apologies, I misread your previous e-mail and had interpreted it
>> as you claiming again that this broke things for those of you "running
>> diskless systems and or seperate /usr." -- this other breakage, these
>> are things we can fix and aren't really large hurdles to climb over.
>
> Mostly true, other than the hurdle of that 0mp mentions in his
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227205
> We need to remember that we cannot simply switch to
> the new mechanism as it is only available in 12-CURRENT
> and soon in 11-STABLE (and 11.2).
>
> I am not sure how to handle that with the users, it is a operational
> interface change in how limits are done for these ports and probably
> is going to break a lot of peoples systems if they try to update
> from 11.1 to 11.2 because there /etc/rc.conf file is full of old
> stuff that this new stuff is incompatible with.
>
> IMHO, it would be best to post pone this change to 12, as people
> are more willing to suffer painful upgrades when going between
> major versions.
>

Right- so, back out this MFC (and the subsequent FreeBSD_version bump)
and fix the ports to do the right thing for 12.x while that's still
not a technically supported branch?

>>
>> We just need people like 0mp that are actually inclined to address it
>> in ports, and we need to actually communicate changes like this with
>> ports 

Re: svn commit: r331880 - stable/11/etc

[Kyle Evans]

On Mon, Apr 9, 2018 at 9:29 AM, Shawn Webb  wrote:
> On Mon, Apr 02, 2018 at 03:28:48PM +, Kyle Evans wrote:
>> Author: kevans
>> Date: Mon Apr  2 15:28:48 2018
>> New Revision: 331880
>> URL: https://svnweb.freebsd.org/changeset/base/331880
>>
>> Log:
>>   MFC r328331: Support configuring arbitrary limits(1) for any rc.conf daemon
>>
>>   Usage is ${name}_limits, and the argument is any flags accepted by
>>   limits(1), such as `-n 100' (e.g. only allow 100 open files).
>
> A HardenedBSD user has reported an issue with this commit:
>
> https://twitter.com/0x666c7578/status/982901931969597440
>

The mariadb ports should be good with this after ports r466451,
tracking PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227205
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r331880 - stable/11/etc

[Rodney W. Grimes]

> On Mon, Apr 9, 2018 at 10:30 AM, Rodney W. Grimes
>  wrote:
> >> On Mon, Apr 9, 2018 at 10:14 AM, Rodney W. Grimes
> >>  wrote:
> >> >> On Mon, Apr 9, 2018 at 9:46 AM, Rodney W. Grimes
> >> >>  wrote:
> >> >> >> On 04/02/18 17:39, Rodney W. Grimes wrote:
> >> >> >> >> Author: kevans
> >> >> >> >> Date: Mon Apr  2 15:28:48 2018
> >> >> >> >> New Revision: 331880
> >> >> >> >> URL: https://svnweb.freebsd.org/changeset/base/331880
> >> >> >> >>
> >> >> >> >> Log:
> >> >> >> >>MFC r328331: Support configuring arbitrary limits(1) for any 
> >> >> >> >> rc.conf daemon
> >> >> >> >>
> >> >> >> >>Usage is ${name}_limits, and the argument is any flags 
> >> >> >> >> accepted by
> >> >> >> >>limits(1), such as `-n 100' (e.g. only allow 100 open files).
> >> >> >> >>
> >> >> >> >> Modified:
> >> >> >> >>stable/11/etc/rc.subr
> >> >> >> >> Directory Properties:
> >> >> >> >>stable/11/   (props changed)
> >> >> >> >>
> >> >> >> >> Modified: stable/11/etc/rc.subr
> >> >> >> >> ==
> >> >> >> >> --- stable/11/etc/rc.subr  Mon Apr  2 15:07:41 2018
> >> >> >> >> (r331879)
> >> >> >> >> +++ stable/11/etc/rc.subr  Mon Apr  2 15:28:48 2018
> >> >> >> >> (r331880)
> >> >> >> >> @@ -773,6 +773,8 @@ check_startmsgs()
> >> >> >> >>   #
> >> >> >> >>   #${name}_login_class n   Login class to use, else 
> >> >> >> >> "daemon".
> >> >> >> >>   #
> >> >> >> >> +# ${name}_limits  n   limits(1) to apply to ${command}.
> >> >> >> >> +#
> >> >> >> >
> >> >> >> > Caution, limits(1) is in /usr/bin, this code can fail if used 
> >> >> >> > before
> >> >> >> > /usr is mounted.  (Ie, our rc.initdiskless) is probably broken by
> >> >> >> > this change if a call is made to limits.
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >> Sorry for jumping on this so late.  This is also an issue in CURRENT,
> >> >> >> and has been since at least 2016.
> >> >> >
> >> >> > I was aware that it was an issue and why I made a comment about it
> >> >> > being MFC'ed.  Though I had forgot a bug report existed.
> >> >>
> >> >> I'm kind of surprised we haven't had more complaints about this- the
> >> >> original commit for this stuff landed before stable/11 was even
> >> >> branched, so it's been broken for all of 11.x's lifetime.
> >> >
> >> > History has taught me it takes a long time for this type of
> >> > breakage to usually surface in a noticable way.  Also I think
> >> > until you merged this last ${name}_limits thing it actually
> >> > didn't cause an issue, except for the few like me running
> >> > diskless systems and or seperate /usr.
> >>
> >> I don't see how this merge could possibly have been the cause of any
> >> claimed issues- like I said before, it didn't add any limits
> >> invocations, it added an arg to the limits invocation that already
> >> existed. You can see this pretty clearly from the diff, we didn't even
> >> change any conditions for limits to be invoked.
> >
> > limits_mysql="NO" is defined by the startup script for mysql,
> > that now causes /etc/rc to try and use that variable in a
> > different way.
> >
> > You added a variable, one that was already in use by some other
> > /etc/rc* related component.  Collision of differening uses is
> > causing errors.
> >
> 
> Ah, apologies, I misread your previous e-mail and had interpreted it
> as you claiming again that this broke things for those of you "running
> diskless systems and or seperate /usr." -- this other breakage, these
> are things we can fix and aren't really large hurdles to climb over.

Mostly true, other than the hurdle of that 0mp mentions in his
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227205
We need to remember that we cannot simply switch to
the new mechanism as it is only available in 12-CURRENT
and soon in 11-STABLE (and 11.2). 

I am not sure how to handle that with the users, it is a operational
interface change in how limits are done for these ports and probably
is going to break a lot of peoples systems if they try to update
from 11.1 to 11.2 because there /etc/rc.conf file is full of old
stuff that this new stuff is incompatible with.

IMHO, it would be best to post pone this change to 12, as people
are more willing to suffer painful upgrades when going between
major versions.

> 
> We just need people like 0mp that are actually inclined to address it
> in ports, and we need to actually communicate changes like this with
> ports people and assess what's going to break and make a plan to get
> it fixed.

Problem was/is no one had the foresight to see the ports breakage
coming and avoid it in some way.  That happens, its engineering,
lets find a fix and move on.

> IMO this in particular wasn't a major change, and it shouldn't have
> been too big of a deal (unlike the commit that it built upon). I don't
> think it 

Re: svn commit: r331880 - stable/11/etc

[Kyle Evans]

On Mon, Apr 9, 2018 at 10:30 AM, Rodney W. Grimes
 wrote:
>> On Mon, Apr 9, 2018 at 10:14 AM, Rodney W. Grimes
>>  wrote:
>> >> On Mon, Apr 9, 2018 at 9:46 AM, Rodney W. Grimes
>> >>  wrote:
>> >> >> On 04/02/18 17:39, Rodney W. Grimes wrote:
>> >> >> >> Author: kevans
>> >> >> >> Date: Mon Apr  2 15:28:48 2018
>> >> >> >> New Revision: 331880
>> >> >> >> URL: https://svnweb.freebsd.org/changeset/base/331880
>> >> >> >>
>> >> >> >> Log:
>> >> >> >>MFC r328331: Support configuring arbitrary limits(1) for any 
>> >> >> >> rc.conf daemon
>> >> >> >>
>> >> >> >>Usage is ${name}_limits, and the argument is any flags accepted 
>> >> >> >> by
>> >> >> >>limits(1), such as `-n 100' (e.g. only allow 100 open files).
>> >> >> >>
>> >> >> >> Modified:
>> >> >> >>stable/11/etc/rc.subr
>> >> >> >> Directory Properties:
>> >> >> >>stable/11/   (props changed)
>> >> >> >>
>> >> >> >> Modified: stable/11/etc/rc.subr
>> >> >> >> ==
>> >> >> >> --- stable/11/etc/rc.subr  Mon Apr  2 15:07:41 2018(r331879)
>> >> >> >> +++ stable/11/etc/rc.subr  Mon Apr  2 15:28:48 2018(r331880)
>> >> >> >> @@ -773,6 +773,8 @@ check_startmsgs()
>> >> >> >>   #
>> >> >> >>   #${name}_login_class n   Login class to use, else 
>> >> >> >> "daemon".
>> >> >> >>   #
>> >> >> >> +# ${name}_limits  n   limits(1) to apply to ${command}.
>> >> >> >> +#
>> >> >> >
>> >> >> > Caution, limits(1) is in /usr/bin, this code can fail if used before
>> >> >> > /usr is mounted.  (Ie, our rc.initdiskless) is probably broken by
>> >> >> > this change if a call is made to limits.
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> Sorry for jumping on this so late.  This is also an issue in CURRENT,
>> >> >> and has been since at least 2016.
>> >> >
>> >> > I was aware that it was an issue and why I made a comment about it
>> >> > being MFC'ed.  Though I had forgot a bug report existed.
>> >>
>> >> I'm kind of surprised we haven't had more complaints about this- the
>> >> original commit for this stuff landed before stable/11 was even
>> >> branched, so it's been broken for all of 11.x's lifetime.
>> >
>> > History has taught me it takes a long time for this type of
>> > breakage to usually surface in a noticable way.  Also I think
>> > until you merged this last ${name}_limits thing it actually
>> > didn't cause an issue, except for the few like me running
>> > diskless systems and or seperate /usr.
>>
>> I don't see how this merge could possibly have been the cause of any
>> claimed issues- like I said before, it didn't add any limits
>> invocations, it added an arg to the limits invocation that already
>> existed. You can see this pretty clearly from the diff, we didn't even
>> change any conditions for limits to be invoked.
>
> limits_mysql="NO" is defined by the startup script for mysql,
> that now causes /etc/rc to try and use that variable in a
> different way.
>
> You added a variable, one that was already in use by some other
> /etc/rc* related component.  Collision of differening uses is
> causing errors.
>

Ah, apologies, I misread your previous e-mail and had interpreted it
as you claiming again that this broke things for those of you "running
diskless systems and or seperate /usr." -- this other breakage, these
are things we can fix and aren't really large hurdles to climb over.

We just need people like 0mp that are actually inclined to address it
in ports, and we need to actually communicate changes like this with
ports people and assess what's going to break and make a plan to get
it fixed.

IMO this in particular wasn't a major change, and it shouldn't have
been too big of a deal (unlike the commit that it built upon). I don't
think it should've been broken in head for two months in the various
ports that 0mp has identified- even if people don't run these
databases on head, we should've assessed the fallout and fixed it
somewhere in the two month's time. We're not talking half the ports
tree, we're talking < 30 ports. =(
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r331880 - stable/11/etc

[Rodney W. Grimes]

> On Mon, Apr 9, 2018 at 10:14 AM, Rodney W. Grimes
>  wrote:
> >> On Mon, Apr 9, 2018 at 9:46 AM, Rodney W. Grimes
> >>  wrote:
> >> >> On 04/02/18 17:39, Rodney W. Grimes wrote:
> >> >> >> Author: kevans
> >> >> >> Date: Mon Apr  2 15:28:48 2018
> >> >> >> New Revision: 331880
> >> >> >> URL: https://svnweb.freebsd.org/changeset/base/331880
> >> >> >>
> >> >> >> Log:
> >> >> >>MFC r328331: Support configuring arbitrary limits(1) for any 
> >> >> >> rc.conf daemon
> >> >> >>
> >> >> >>Usage is ${name}_limits, and the argument is any flags accepted by
> >> >> >>limits(1), such as `-n 100' (e.g. only allow 100 open files).
> >> >> >>
> >> >> >> Modified:
> >> >> >>stable/11/etc/rc.subr
> >> >> >> Directory Properties:
> >> >> >>stable/11/   (props changed)
> >> >> >>
> >> >> >> Modified: stable/11/etc/rc.subr
> >> >> >> ==
> >> >> >> --- stable/11/etc/rc.subr  Mon Apr  2 15:07:41 2018(r331879)
> >> >> >> +++ stable/11/etc/rc.subr  Mon Apr  2 15:28:48 2018(r331880)
> >> >> >> @@ -773,6 +773,8 @@ check_startmsgs()
> >> >> >>   #
> >> >> >>   #${name}_login_class n   Login class to use, else "daemon".
> >> >> >>   #
> >> >> >> +# ${name}_limits  n   limits(1) to apply to ${command}.
> >> >> >> +#
> >> >> >
> >> >> > Caution, limits(1) is in /usr/bin, this code can fail if used before
> >> >> > /usr is mounted.  (Ie, our rc.initdiskless) is probably broken by
> >> >> > this change if a call is made to limits.
> >> >> >
> >> >> >
> >> >>
> >> >> Sorry for jumping on this so late.  This is also an issue in CURRENT,
> >> >> and has been since at least 2016.
> >> >
> >> > I was aware that it was an issue and why I made a comment about it
> >> > being MFC'ed.  Though I had forgot a bug report existed.
> >>
> >> I'm kind of surprised we haven't had more complaints about this- the
> >> original commit for this stuff landed before stable/11 was even
> >> branched, so it's been broken for all of 11.x's lifetime.
> >
> > History has taught me it takes a long time for this type of
> > breakage to usually surface in a noticable way.  Also I think
> > until you merged this last ${name}_limits thing it actually
> > didn't cause an issue, except for the few like me running
> > diskless systems and or seperate /usr.
> 
> I don't see how this merge could possibly have been the cause of any
> claimed issues- like I said before, it didn't add any limits
> invocations, it added an arg to the limits invocation that already
> existed. You can see this pretty clearly from the diff, we didn't even
> change any conditions for limits to be invoked.

limits_mysql="NO" is defined by the startup script for mysql,
that now causes /etc/rc to try and use that variable in a
different way.

You added a variable, one that was already in use by some other
/etc/rc* related component.  Collision of differening uses is
causing errors.


> > This latest issue is a name space collision between base and ports.
> >
> > People who see limits issues due to missing /usr files usually
> > know how to work around it, and they do, they just cp /usr/bin/limits
> > to /bin, and do not submit a bug report or send an email.
> >
> 
> That saddens me. =/

Sorry for the reality check.  Breakage can often take years before
someone notices some side effect that was never for seen.  Its just
the nature of the beast.

I am *still* dealing with the fall out that was the FreeBSD 6.0
conversion from standalone ata code to ata over cam.  Our error
reporting and handling is still not as robust as that which I
have in my 5.4p8 based systems.

I think it was near 2 years before someone noticed that a change
to telldir() caused Samba performance to go in the tank.  And iirc
that change was done to make it Posix compliant!

I try to keep in mind that every bug being fixed often has an
unknown new bug being introduced, and some times 2.  If you
do not believe this, go look at the coverty graphs, despite
the fact that many coverty errors have been fixed, we are
actually increasing the number of issues over the long term.

In the statistic process model of manufacturing when you see
this the first thing that comes to mind is "we have an open
loop and out of control manufacturing system".

Now that saddens me. =/


-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r331880 - stable/11/etc

[Kyle Evans]

On Mon, Apr 9, 2018 at 10:14 AM, Rodney W. Grimes
 wrote:
> [ Charset UTF-8 unsupported, converting... ]
>> On Mon, Apr 9, 2018 at 9:46 AM, Rodney W. Grimes
>>  wrote:
>> >> On 04/02/18 17:39, Rodney W. Grimes wrote:
>> >> >> Author: kevans
>> >> >> Date: Mon Apr  2 15:28:48 2018
>> >> >> New Revision: 331880
>> >> >> URL: https://svnweb.freebsd.org/changeset/base/331880
>> >> >>
>> >> >> Log:
>> >> >>MFC r328331: Support configuring arbitrary limits(1) for any 
>> >> >> rc.conf daemon
>> >> >>
>> >> >>Usage is ${name}_limits, and the argument is any flags accepted by
>> >> >>limits(1), such as `-n 100' (e.g. only allow 100 open files).
>> >> >>
>> >> >> Modified:
>> >> >>stable/11/etc/rc.subr
>> >> >> Directory Properties:
>> >> >>stable/11/   (props changed)
>> >> >>
>> >> >> Modified: stable/11/etc/rc.subr
>> >> >> ==
>> >> >> --- stable/11/etc/rc.subr  Mon Apr  2 15:07:41 2018(r331879)
>> >> >> +++ stable/11/etc/rc.subr  Mon Apr  2 15:28:48 2018(r331880)
>> >> >> @@ -773,6 +773,8 @@ check_startmsgs()
>> >> >>   #
>> >> >>   #${name}_login_class n   Login class to use, else "daemon".
>> >> >>   #
>> >> >> +# ${name}_limits  n   limits(1) to apply to ${command}.
>> >> >> +#
>> >> >
>> >> > Caution, limits(1) is in /usr/bin, this code can fail if used before
>> >> > /usr is mounted.  (Ie, our rc.initdiskless) is probably broken by
>> >> > this change if a call is made to limits.
>> >> >
>> >> >
>> >>
>> >> Sorry for jumping on this so late.  This is also an issue in CURRENT,
>> >> and has been since at least 2016.
>> >
>> > I was aware that it was an issue and why I made a comment about it
>> > being MFC'ed.  Though I had forgot a bug report existed.
>>
>> I'm kind of surprised we haven't had more complaints about this- the
>> original commit for this stuff landed before stable/11 was even
>> branched, so it's been broken for all of 11.x's lifetime.
>
> History has taught me it takes a long time for this type of
> breakage to usually surface in a noticable way.  Also I think
> until you merged this last ${name}_limits thing it actually
> didn't cause an issue, except for the few like me running
> diskless systems and or seperate /usr.

I don't see how this merge could possibly have been the cause of any
claimed issues- like I said before, it didn't add any limits
invocations, it added an arg to the limits invocation that already
existed. You can see this pretty clearly from the diff, we didn't even
change any conditions for limits to be invoked.

>
> This latest issue is a name space collision between base and ports.
>
> People who see limits issues due to missing /usr files usually
> know how to work around it, and they do, they just cp /usr/bin/limits
> to /bin, and do not submit a bug report or send an email.
>

That saddens me. =/
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r331880 - stable/11/etc

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> On Mon, Apr 9, 2018 at 9:46 AM, Rodney W. Grimes
>  wrote:
> >> On 04/02/18 17:39, Rodney W. Grimes wrote:
> >> >> Author: kevans
> >> >> Date: Mon Apr  2 15:28:48 2018
> >> >> New Revision: 331880
> >> >> URL: https://svnweb.freebsd.org/changeset/base/331880
> >> >>
> >> >> Log:
> >> >>MFC r328331: Support configuring arbitrary limits(1) for any rc.conf 
> >> >> daemon
> >> >>
> >> >>Usage is ${name}_limits, and the argument is any flags accepted by
> >> >>limits(1), such as `-n 100' (e.g. only allow 100 open files).
> >> >>
> >> >> Modified:
> >> >>stable/11/etc/rc.subr
> >> >> Directory Properties:
> >> >>stable/11/   (props changed)
> >> >>
> >> >> Modified: stable/11/etc/rc.subr
> >> >> ==
> >> >> --- stable/11/etc/rc.subr  Mon Apr  2 15:07:41 2018(r331879)
> >> >> +++ stable/11/etc/rc.subr  Mon Apr  2 15:28:48 2018(r331880)
> >> >> @@ -773,6 +773,8 @@ check_startmsgs()
> >> >>   #
> >> >>   #${name}_login_class n   Login class to use, else "daemon".
> >> >>   #
> >> >> +# ${name}_limits  n   limits(1) to apply to ${command}.
> >> >> +#
> >> >
> >> > Caution, limits(1) is in /usr/bin, this code can fail if used before
> >> > /usr is mounted.  (Ie, our rc.initdiskless) is probably broken by
> >> > this change if a call is made to limits.
> >> >
> >> >
> >>
> >> Sorry for jumping on this so late.  This is also an issue in CURRENT,
> >> and has been since at least 2016.
> >
> > I was aware that it was an issue and why I made a comment about it
> > being MFC'ed.  Though I had forgot a bug report existed.
> 
> I'm kind of surprised we haven't had more complaints about this- the
> original commit for this stuff landed before stable/11 was even
> branched, so it's been broken for all of 11.x's lifetime.

History has taught me it takes a long time for this type of
breakage to usually surface in a noticable way.  Also I think
until you merged this last ${name}_limits thing it actually
didn't cause an issue, except for the few like me running
diskless systems and or seperate /usr.

This latest issue is a name space collision between base and ports.

People who see limits issues due to missing /usr files usually
know how to work around it, and they do, they just cp /usr/bin/limits
to /bin, and do not submit a bug report or send an email.

> >> See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206291
> >
> > This bug is rat holed as it has no FreeBSD-foo@ in the cc list.
> >
> >
> > --
> > Rod Grimes 
> > rgri...@freebsd.org
> >
> 

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r331880 - stable/11/etc

[Rodney W. Grimes]

-- Start of PGP signed section.
> On Mon, Apr 09, 2018 at 09:33:38AM -0500, Kyle Evans wrote:
> > On Mon, Apr 9, 2018 at 9:29 AM, Shawn Webb  
> > wrote:
> > > On Mon, Apr 02, 2018 at 03:28:48PM +, Kyle Evans wrote:
> > >> Author: kevans
> > >> Date: Mon Apr  2 15:28:48 2018
> > >> New Revision: 331880
> > >> URL: https://svnweb.freebsd.org/changeset/base/331880
> > >>
> > >> Log:
> > >>   MFC r328331: Support configuring arbitrary limits(1) for any rc.conf 
> > >> daemon
> > >>
> > >>   Usage is ${name}_limits, and the argument is any flags accepted by
> > >>   limits(1), such as `-n 100' (e.g. only allow 100 open files).
> > >
> > > A HardenedBSD user has reported an issue with this commit:
> > >
> > > https://twitter.com/0x666c7578/status/982901931969597440
> > >
> > 
> > The mariadb ports should be good with this after ports r466451,
> > tracking PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227205
> 
> Awesome. Thanks!

Maybe not so awesome, as now if we go trying to fix the earlier
issues it also now effects a pile of ports... *sigh*.

-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r331880 - stable/11/etc

[Kyle Evans]

On Mon, Apr 9, 2018 at 9:46 AM, Rodney W. Grimes
 wrote:
>> On 04/02/18 17:39, Rodney W. Grimes wrote:
>> >> Author: kevans
>> >> Date: Mon Apr  2 15:28:48 2018
>> >> New Revision: 331880
>> >> URL: https://svnweb.freebsd.org/changeset/base/331880
>> >>
>> >> Log:
>> >>MFC r328331: Support configuring arbitrary limits(1) for any rc.conf 
>> >> daemon
>> >>
>> >>Usage is ${name}_limits, and the argument is any flags accepted by
>> >>limits(1), such as `-n 100' (e.g. only allow 100 open files).
>> >>
>> >> Modified:
>> >>stable/11/etc/rc.subr
>> >> Directory Properties:
>> >>stable/11/   (props changed)
>> >>
>> >> Modified: stable/11/etc/rc.subr
>> >> ==
>> >> --- stable/11/etc/rc.subr  Mon Apr  2 15:07:41 2018(r331879)
>> >> +++ stable/11/etc/rc.subr  Mon Apr  2 15:28:48 2018(r331880)
>> >> @@ -773,6 +773,8 @@ check_startmsgs()
>> >>   #
>> >>   #${name}_login_class n   Login class to use, else "daemon".
>> >>   #
>> >> +# ${name}_limits  n   limits(1) to apply to ${command}.
>> >> +#
>> >
>> > Caution, limits(1) is in /usr/bin, this code can fail if used before
>> > /usr is mounted.  (Ie, our rc.initdiskless) is probably broken by
>> > this change if a call is made to limits.
>> >
>> >
>>
>> Sorry for jumping on this so late.  This is also an issue in CURRENT,
>> and has been since at least 2016.
>
> I was aware that it was an issue and why I made a comment about it
> being MFC'ed.  Though I had forgot a bug report existed.

I'm kind of surprised we haven't had more complaints about this- the
original commit for this stuff landed before stable/11 was even
branched, so it's been broken for all of 11.x's lifetime.

>> See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206291
>
> This bug is rat holed as it has no FreeBSD-foo@ in the cc list.
>
>
> --
> Rod Grimes rgri...@freebsd.org
>
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r331880 - stable/11/etc

[Rodney W. Grimes]

Adding Devin Teske to cc:

> On Mon, Apr 9, 2018 at 9:04 AM, Niclas Zeising
>  wrote:
> > On 04/02/18 17:39, Rodney W. Grimes wrote:
> >>>
> >>> Author: kevans
> >>> Date: Mon Apr  2 15:28:48 2018
> >>> New Revision: 331880
> >>> URL: https://svnweb.freebsd.org/changeset/base/331880
> >>>
> >>> Log:
> >>>MFC r328331: Support configuring arbitrary limits(1) for any rc.conf
> >>> daemon
> >>>   Usage is ${name}_limits, and the argument is any flags accepted by
> >>>limits(1), such as `-n 100' (e.g. only allow 100 open files).
> >>>
> >>> Modified:
> >>>stable/11/etc/rc.subr
> >>> Directory Properties:
> >>>stable/11/   (props changed)
> >>>
> >>> Modified: stable/11/etc/rc.subr
> >>>
> >>> ==
> >>> --- stable/11/etc/rc.subr   Mon Apr  2 15:07:41 2018(r331879)
> >>> +++ stable/11/etc/rc.subr   Mon Apr  2 15:28:48 2018(r331880)
> >>> @@ -773,6 +773,8 @@ check_startmsgs()
> >>>   #
> >>>   # ${name}_login_class n   Login class to use, else "daemon".
> >>>   #
> >>> +#  ${name}_limits  n   limits(1) to apply to ${command}.
> >>> +#
> >>
> >>
> >> Caution, limits(1) is in /usr/bin, this code can fail if used before
> >> /usr is mounted.  (Ie, our rc.initdiskless) is probably broken by
> >> this change if a call is made to limits.
> >>
> >>
> >
> > Sorry for jumping on this so late.  This is also an issue in CURRENT, and
> > has been since at least 2016.
> >
> > See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206291
> >
> 
> I kind of like Cy's approach in Comment #7.. scripts that start pretty
> early, at least, are bound to trip over all kinds of issues.

I think you mean comment #5, with a specific patch to rc.d/ddb in #7?
If so I like that approach.

> I don't think it's a good idea to work around this in rc.subr like his
> "relief valve" patch since it'll just create hidden inconsistencies in
> some of these things. _limits isn't getting applied, but it's not
> obvious that _limits isn't getting applied because we just silently
> work around it. Before we know it, we'll be adding something else
> that's nice in the general case but not applicable for some of these
> earlier bits.

Agree fully with that, changing behavior based on avaliablility of
a critical function would be a POLA issue.

> Rod, what are you thoughts on these approaches?

I am ok with Cy's #5/#7 fix.  I would like to look closer at this
limits(1) issue, as I do not understand why /etc/rc* suddenly grew
the need to start tossing limits on programs in a generic way.

Also if a specific user has a specific need to put a limit on a
program could that not be done with:

program_foo_limits="-C blah blah"
foo_program="limits ${program_foo_limits} foo"

in /etc/rc.conf or where ever else it is valid to do this.

I would also like to ask Devin Teske to weigh in on these issues,
so have added them to the CC: of this reply.


-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r331880 - stable/11/etc

[Rodney W. Grimes]

> On 04/02/18 17:39, Rodney W. Grimes wrote:
> >> Author: kevans
> >> Date: Mon Apr  2 15:28:48 2018
> >> New Revision: 331880
> >> URL: https://svnweb.freebsd.org/changeset/base/331880
> >>
> >> Log:
> >>MFC r328331: Support configuring arbitrary limits(1) for any rc.conf 
> >> daemon
> >>
> >>Usage is ${name}_limits, and the argument is any flags accepted by
> >>limits(1), such as `-n 100' (e.g. only allow 100 open files).
> >>
> >> Modified:
> >>stable/11/etc/rc.subr
> >> Directory Properties:
> >>stable/11/   (props changed)
> >>
> >> Modified: stable/11/etc/rc.subr
> >> ==
> >> --- stable/11/etc/rc.subr  Mon Apr  2 15:07:41 2018(r331879)
> >> +++ stable/11/etc/rc.subr  Mon Apr  2 15:28:48 2018(r331880)
> >> @@ -773,6 +773,8 @@ check_startmsgs()
> >>   #
> >>   #${name}_login_class n   Login class to use, else "daemon".
> >>   #
> >> +# ${name}_limits  n   limits(1) to apply to ${command}.
> >> +#
> > 
> > Caution, limits(1) is in /usr/bin, this code can fail if used before
> > /usr is mounted.  (Ie, our rc.initdiskless) is probably broken by
> > this change if a call is made to limits.
> > 
> > 
> 
> Sorry for jumping on this so late.  This is also an issue in CURRENT, 
> and has been since at least 2016.

I was aware that it was an issue and why I made a comment about it
being MFC'ed.  Though I had forgot a bug report existed.

> See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206291

This bug is rat holed as it has no FreeBSD-foo@ in the cc list.


-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r331880 - stable/11/etc

[Shawn Webb]

On Mon, Apr 09, 2018 at 09:33:38AM -0500, Kyle Evans wrote:
> On Mon, Apr 9, 2018 at 9:29 AM, Shawn Webb  wrote:
> > On Mon, Apr 02, 2018 at 03:28:48PM +, Kyle Evans wrote:
> >> Author: kevans
> >> Date: Mon Apr  2 15:28:48 2018
> >> New Revision: 331880
> >> URL: https://svnweb.freebsd.org/changeset/base/331880
> >>
> >> Log:
> >>   MFC r328331: Support configuring arbitrary limits(1) for any rc.conf 
> >> daemon
> >>
> >>   Usage is ${name}_limits, and the argument is any flags accepted by
> >>   limits(1), such as `-n 100' (e.g. only allow 100 open files).
> >
> > A HardenedBSD user has reported an issue with this commit:
> >
> > https://twitter.com/0x666c7578/status/982901931969597440
> >
> 
> The mariadb ports should be good with this after ports r466451,
> tracking PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227205

Awesome. Thanks!

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE


signature.asc
Description: PGP signature

Re: svn commit: r331880 - stable/11/etc

[Shawn Webb]

On Mon, Apr 02, 2018 at 03:28:48PM +, Kyle Evans wrote:
> Author: kevans
> Date: Mon Apr  2 15:28:48 2018
> New Revision: 331880
> URL: https://svnweb.freebsd.org/changeset/base/331880
> 
> Log:
>   MFC r328331: Support configuring arbitrary limits(1) for any rc.conf daemon
>   
>   Usage is ${name}_limits, and the argument is any flags accepted by
>   limits(1), such as `-n 100' (e.g. only allow 100 open files).

A HardenedBSD user has reported an issue with this commit:

https://twitter.com/0x666c7578/status/982901931969597440

Thanks,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE


signature.asc
Description: PGP signature

Re: svn commit: r331880 - stable/11/etc

[Kyle Evans]

On Mon, Apr 9, 2018 at 9:04 AM, Niclas Zeising
 wrote:
> On 04/02/18 17:39, Rodney W. Grimes wrote:
>>>
>>> Author: kevans
>>> Date: Mon Apr  2 15:28:48 2018
>>> New Revision: 331880
>>> URL: https://svnweb.freebsd.org/changeset/base/331880
>>>
>>> Log:
>>>MFC r328331: Support configuring arbitrary limits(1) for any rc.conf
>>> daemon
>>>   Usage is ${name}_limits, and the argument is any flags accepted by
>>>limits(1), such as `-n 100' (e.g. only allow 100 open files).
>>>
>>> Modified:
>>>stable/11/etc/rc.subr
>>> Directory Properties:
>>>stable/11/   (props changed)
>>>
>>> Modified: stable/11/etc/rc.subr
>>>
>>> ==
>>> --- stable/11/etc/rc.subr   Mon Apr  2 15:07:41 2018(r331879)
>>> +++ stable/11/etc/rc.subr   Mon Apr  2 15:28:48 2018(r331880)
>>> @@ -773,6 +773,8 @@ check_startmsgs()
>>>   #
>>>   # ${name}_login_class n   Login class to use, else "daemon".
>>>   #
>>> +#  ${name}_limits  n   limits(1) to apply to ${command}.
>>> +#
>>
>>
>> Caution, limits(1) is in /usr/bin, this code can fail if used before
>> /usr is mounted.  (Ie, our rc.initdiskless) is probably broken by
>> this change if a call is made to limits.
>>
>>
>
> Sorry for jumping on this so late.  This is also an issue in CURRENT, and
> has been since at least 2016.
>
> See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206291
>

I kind of like Cy's approach in Comment #7.. scripts that start pretty
early, at least, are bound to trip over all kinds of issues.

I don't think it's a good idea to work around this in rc.subr like his
"relief valve" patch since it'll just create hidden inconsistencies in
some of these things. _limits isn't getting applied, but it's not
obvious that _limits isn't getting applied because we just silently
work around it. Before we know it, we'll be adding something else
that's nice in the general case but not applicable for some of these
earlier bits.

Rod, what are you thoughts on these approaches?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r331880 - stable/11/etc

[Niclas Zeising]

On 04/02/18 17:39, Rodney W. Grimes wrote:

Author: kevans
Date: Mon Apr  2 15:28:48 2018
New Revision: 331880
URL: https://svnweb.freebsd.org/changeset/base/331880

Log:
   MFC r328331: Support configuring arbitrary limits(1) for any rc.conf daemon
   
   Usage is ${name}_limits, and the argument is any flags accepted by

   limits(1), such as `-n 100' (e.g. only allow 100 open files).

Modified:
   stable/11/etc/rc.subr
Directory Properties:
   stable/11/   (props changed)

Modified: stable/11/etc/rc.subr
==
--- stable/11/etc/rc.subr   Mon Apr  2 15:07:41 2018(r331879)
+++ stable/11/etc/rc.subr   Mon Apr  2 15:28:48 2018(r331880)
@@ -773,6 +773,8 @@ check_startmsgs()
  #
  # ${name}_login_class n   Login class to use, else "daemon".
  #
+#  ${name}_limits  n   limits(1) to apply to ${command}.
+#


Caution, limits(1) is in /usr/bin, this code can fail if used before
/usr is mounted.  (Ie, our rc.initdiskless) is probably broken by
this change if a call is made to limits.




Sorry for jumping on this so late.  This is also an issue in CURRENT, 
and has been since at least 2016.


See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206291

Regards
--
Niclas
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r331880 - stable/11/etc

[Kyle Evans]

On Mon, Apr 2, 2018 at 10:39 AM, Rodney W. Grimes
 wrote:
>> Author: kevans
>> Date: Mon Apr  2 15:28:48 2018
>> New Revision: 331880
>> URL: https://svnweb.freebsd.org/changeset/base/331880
>>
>> Log:
>>   MFC r328331: Support configuring arbitrary limits(1) for any rc.conf daemon
>>
>>   Usage is ${name}_limits, and the argument is any flags accepted by
>>   limits(1), such as `-n 100' (e.g. only allow 100 open files).
>>
>> Modified:
>>   stable/11/etc/rc.subr
>> Directory Properties:
>>   stable/11/   (props changed)
>>
>> Modified: stable/11/etc/rc.subr
>> ==
>> --- stable/11/etc/rc.subr Mon Apr  2 15:07:41 2018(r331879)
>> +++ stable/11/etc/rc.subr Mon Apr  2 15:28:48 2018(r331880)
>> @@ -773,6 +773,8 @@ check_startmsgs()
>>  #
>>  #${name}_login_class n   Login class to use, else "daemon".
>>  #
>> +#${name}_limits  n   limits(1) to apply to ${command}.
>> +#
>
> Caution, limits(1) is in /usr/bin, this code can fail if used before
> /usr is mounted.  (Ie, our rc.initdiskless) is probably broken by
> this change if a call is made to limits.
>

I believe this is a non-issue in this case-- this didn't add any
limits(1) invocations, it just allowed flags to be passed to the
limits(1) invocation that was already being made.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r331880 - stable/11/etc

[Rodney W. Grimes]

> Author: kevans
> Date: Mon Apr  2 15:28:48 2018
> New Revision: 331880
> URL: https://svnweb.freebsd.org/changeset/base/331880
> 
> Log:
>   MFC r328331: Support configuring arbitrary limits(1) for any rc.conf daemon
>   
>   Usage is ${name}_limits, and the argument is any flags accepted by
>   limits(1), such as `-n 100' (e.g. only allow 100 open files).
> 
> Modified:
>   stable/11/etc/rc.subr
> Directory Properties:
>   stable/11/   (props changed)
> 
> Modified: stable/11/etc/rc.subr
> ==
> --- stable/11/etc/rc.subr Mon Apr  2 15:07:41 2018(r331879)
> +++ stable/11/etc/rc.subr Mon Apr  2 15:28:48 2018(r331880)
> @@ -773,6 +773,8 @@ check_startmsgs()
>  #
>  #${name}_login_class n   Login class to use, else "daemon".
>  #
> +#${name}_limits  n   limits(1) to apply to ${command}.
> +#

Caution, limits(1) is in /usr/bin, this code can fail if used before
/usr is mounted.  (Ie, our rc.initdiskless) is probably broken by
this change if a call is made to limits.


-- 
Rod Grimes rgri...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r331880 - stable/11/etc

[Kyle Evans]

Author: kevans
Date: Mon Apr  2 15:28:48 2018
New Revision: 331880
URL: https://svnweb.freebsd.org/changeset/base/331880

Log:
  MFC r328331: Support configuring arbitrary limits(1) for any rc.conf daemon
  
  Usage is ${name}_limits, and the argument is any flags accepted by
  limits(1), such as `-n 100' (e.g. only allow 100 open files).

Modified:
  stable/11/etc/rc.subr
Directory Properties:
  stable/11/   (props changed)

Modified: stable/11/etc/rc.subr
==
--- stable/11/etc/rc.subr   Mon Apr  2 15:07:41 2018(r331879)
+++ stable/11/etc/rc.subr   Mon Apr  2 15:28:48 2018(r331880)
@@ -773,6 +773,8 @@ check_startmsgs()
 #
 #  ${name}_login_class n   Login class to use, else "daemon".
 #
+#  ${name}_limits  n   limits(1) to apply to ${command}.
+#
 #  ${rc_arg}_cmd   n   If set, use this as the method when invoked;
 #  Otherwise, use default command (see below)
 #
@@ -952,7 +954,7 @@ run_rc_command()
_group=\$${name}_group  _groups=\$${name}_groups \
_fib=\$${name}_fib  _env=\$${name}_env \
_prepend=\$${name}_prepend  
_login_class=\${${name}_login_class:-daemon} \
-   _oomprotect=\$${name}_oomprotect
+   _limits=\$${name}_limits_oomprotect=\$${name}_oomprotect
 
if [ -n "$_user" ]; then# unset $_user if running as that user
if [ "$_user" = "$(eval $IDCMD)" ]; then
@@ -1073,7 +1075,7 @@ $command $rc_flags $command_args"
fi
 
# Prepend default limits
-   _doit="$_cd limits -C $_login_class $_doit"
+   _doit="$_cd limits -C $_login_class $_limits $_doit"
 
# run the full command
#
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"