Re: rc.conf.local sorted?
On Wed, May 27, 2020 at 1:16 AM Antoine Jacoutot wrote: > > On Tue, May 26, 2020 at 05:16:44PM +0200, Why 42? The lists account. wrote: > > > > On Mon, May 25, 2020 at 04:51:51PM +0200, Antoine Jacoutot wrote: > > > > ... > > > > It looks as if the file has been sorted e.g. > > > Did you use rcctl(8) ? > > > > Hi Antoine, > > > > You are correct, that does it. I checked the history and after the > > upgrade I had run rcctl to enable sensorsd. Just tested it again and > > running an rcctl enable or disable command causes all the lines of > > /etc/rc.conf.local to be alphabetically sorted. > > > > That seems like a defect to me, what do you think? > > That's what you get when mixing helper tools and manuals edits. > They can work together but only up to a certain point... and in this case, > comments don't fly. > As long as everything works functionnaly, then I'd say we're good and can live > with it. I think it warrants a short note in the manpage of rcctl or rc.conf though. Although I have personally not had this happen to me, I did not expect the behaviour and would have been equally surprised.
Re: rc.conf.local sorted?
On Tue, May 26, 2020 at 05:16:44PM +0200, Why 42? The lists account. wrote: > > On Mon, May 25, 2020 at 04:51:51PM +0200, Antoine Jacoutot wrote: > > > ... > > > It looks as if the file has been sorted e.g. > > Did you use rcctl(8) ? > > Hi Antoine, > > You are correct, that does it. I checked the history and after the > upgrade I had run rcctl to enable sensorsd. Just tested it again and > running an rcctl enable or disable command causes all the lines of > /etc/rc.conf.local to be alphabetically sorted. > > That seems like a defect to me, what do you think? That's what you get when mixing helper tools and manuals edits. They can work together but only up to a certain point... and in this case, comments don't fly. As long as everything works functionnaly, then I'd say we're good and can live with it. -- Antoine
Re: rc.conf.local sorted?
On Mon, May 25, 2020 at 04:51:51PM +0200, Antoine Jacoutot wrote: > > ... > > It looks as if the file has been sorted e.g. > Did you use rcctl(8) ? Hi Antoine, You are correct, that does it. I checked the history and after the upgrade I had run rcctl to enable sensorsd. Just tested it again and running an rcctl enable or disable command causes all the lines of /etc/rc.conf.local to be alphabetically sorted. That seems like a defect to me, what do you think? Thanks for the suggestion! Cheers, Robb.
Re: rc.conf.local sorted?
On Mon, May 25, 2020 at 03:22:11PM +0200, Why 42? The lists account. wrote: > > Hi All, > > After running sysupgrade to update from 6.6 (snapshot) to the newest > version I noticed that the comments I added to /etc/rc.conf.local no > longer made sense (if they ever did :)). > > It looks as if the file has been sorted e.g. > > ... > > # Also increase the number of -b(uffer) frames so as to avoid "stutter" > > under high CPU load. Default (7680) + 1024. See: man sndiod > > # Boot time messages: > > # For NFS > > # Prefer Postfix > > # So this should expose raw device "rsnd/1" the "Burr-Brown from TI USB > > Audio CODEC" (aka "audio1" or "uaudio0") as subdevice: "cyrus" > > # Sound subsystem: sndiod > > # Tell syslog to write mark messages every 30 minutes > > # audio1 at uaudio0 > > # uaudio0 at uhub3 port 1 configuration 1 interface 1 "Burr-Brown from TI > > USB Audio CODEC" rev 1.10/1.00 addr 7 > > # uaudio0: class v1, full-speed, sync, channels: 2 play, 2 rec, 3 ctls > > lockd_flags= > > mountd_flags= > > nfsd_flags=-n 7 -t > > pkg_scripts=messagebus postfix > > portmap_flags= > > sensorsd_flags= > > smtpd_flags=NO > > sndiod_flags="-b 8704 -f rsnd/1 -s cyrus" > > ... > > Is this normal? It doesn't seem like something I would have been likely > to have done manually/accidentally. > > Based on the file mtime it seems as if this happened at boot time, or > perhaps at the time of the first boot after the sysupgrade. > > Strangely sysupgrade itself doesn't have much to say about what it > installed e.g. in messages log I just see: > > sysupgrade: installed new /bsd.upgrade. Old kernel version: OpenBSD > > 6.6-current (GENERIC.MP) #55: Sun Mar 15 02:21:01 MDT 2020 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Per uname I am currently running: 6.7 GENERIC.MP#213 amd64 > > Just wondering if this is the expected behaviour ... Did you use rcctl(8) ? -- Antoine
rc.conf.local sorted?
Hi All, After running sysupgrade to update from 6.6 (snapshot) to the newest version I noticed that the comments I added to /etc/rc.conf.local no longer made sense (if they ever did :)). It looks as if the file has been sorted e.g. > ... > # Also increase the number of -b(uffer) frames so as to avoid "stutter" under > high CPU load. Default (7680) + 1024. See: man sndiod > # Boot time messages: > # For NFS > # Prefer Postfix > # So this should expose raw device "rsnd/1" the "Burr-Brown from TI USB Audio > CODEC" (aka "audio1" or "uaudio0") as subdevice: "cyrus" > # Sound subsystem: sndiod > # Tell syslog to write mark messages every 30 minutes > # audio1 at uaudio0 > # uaudio0 at uhub3 port 1 configuration 1 interface 1 "Burr-Brown from TI USB > Audio CODEC" rev 1.10/1.00 addr 7 > # uaudio0: class v1, full-speed, sync, channels: 2 play, 2 rec, 3 ctls > lockd_flags= > mountd_flags= > nfsd_flags=-n 7 -t > pkg_scripts=messagebus postfix > portmap_flags= > sensorsd_flags= > smtpd_flags=NO > sndiod_flags="-b 8704 -f rsnd/1 -s cyrus" > ... Is this normal? It doesn't seem like something I would have been likely to have done manually/accidentally. Based on the file mtime it seems as if this happened at boot time, or perhaps at the time of the first boot after the sysupgrade. Strangely sysupgrade itself doesn't have much to say about what it installed e.g. in messages log I just see: > sysupgrade: installed new /bsd.upgrade. Old kernel version: OpenBSD > 6.6-current (GENERIC.MP) #55: Sun Mar 15 02:21:01 MDT 2020 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Per uname I am currently running: 6.7 GENERIC.MP#213 amd64 Just wondering if this is the expected behaviour ... Cheers, Robb.
