Re: [PATCH v2] base-files: restore status of system-services after sysupgrade
On 1/12/21 12:05, Sven Roederer wrote: Am Dienstag, 12. Januar 2021, 13:01:45 CET schrieb Adrian Schmutzler: Hello, You don't have to run such complicated script. Just restore /etc/rc.d/ directory after upgrade. Well, that depends on how we want to deal with new services. If I upgrade from 19.07.5 to master, I'd expect new services to be in their default initial state. Restoring "old" rc.d would have everything new disabled. That's counter-intuitive for me. I'm also in favor of not touching new services, which have not been installed before the upgrade. Any update on this? I'd be interested in this service since I often disable DHCP on testing devices. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: WDS stopped working in 21.02, looking for bug in netifd
Small update: Preventing the call to mdev->hotplug_ops->add (and replacing it with return 0) inside the function interface_add_link whenever it is called from interface_handle_link and the string name contains the substring ".sta" seems to "fix" the bug. What kind of hotplug_ops are called for such interfaces? - D.H. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: WDS stopped working in 21.02, looking for bug in netifd
By the way, maybe I should add that both devices are GL.iNet GL-AR150. Also, the configs are only minimally different from the defaults. The only option that could be a bit unusual is having 802.11r enabled. And indeed, after disabling 802.11r, the bug occurs much less often. In fact, without 802.11r, I have not seen the bug for several restarts. I thought I saw the bug once even with 802.11r disabled, but I am not so sure anymore. I now did another dozen restarts (with 802.11r disabled), and the connection always works. Maybe the one time I thought I saw the bug I just wrote "ping" too quickly. I enabled 802.11r again, and the bug appeared again after only one restart. It feels like it is not a coincidence. - D.H. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: uci: unnecessary write accesses
On 2021-09-21 13:19, Florian Eckert wrote:
>
> I have written a small shell script, to track write access to the
> '/etc/config' directory.
> For this task I am using the inotify-tool package [1].
> I am using the inotifywait tool to add the watchers [2] with a small
> shell script and log them to the syslog.
>
> If I change a 'uci' option with the the 'uci' commands, then I get
> create and write events for a temporary file in the '/etc/config/'
> directory.
> I didn't expect it to be like this.
>
> For example, if I now change a file using the 'uci' command, a tmp file
> is created under '/etc/config'.
> Is this correct? Or do we have a problem there.
> I have always thought that for embedded systems with flashes it is
> important to make as few write accesses as possible.
>
> Shell commands to change uci config:
>
> root@st-dev-07 ~ # uci set system.led_Power.trigger=none
> root@st-dev-07 ~ # uci commit system
>
> Log output of my Script:
>
> Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
> {"directory":"/etc/config/","file":".system.uci-fEGgbp","event":"CREATE","time":"09/21/21
>
> 12:50:38"}
> Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
> {"directory":"/etc/config/","file":".system.uci-fEGgbp","event":"MODIFY","time":"09/21/21
>
> 12:50:38"}
> Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
> {"directory":"/etc/config/","file":".system.uci-fEGgbp","event":"MODIFY","time":"09/21/21
>
> 12:50:38"}
> Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
> {"directory":"/etc/config/","file":".system.uci-fEGgbp","event":"CLOSE_WRITE,CLOSE","time":"09/21/21
>
> 12:50:38"}
> Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
> {"directory":"/etc/config/","file":"system","event":"CLOSE_WRITE,CLOSE","time":"09/21/21
>
> 12:50:38"}
> Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
> {"directory":"/etc/config/","file":".system.uci-fEGgbp","event":"ATTRIB","time":"09/21/21
>
> 12:50:38"}
>
> I am bothered about the file '.system.uci-fEGgbp'?
The extra temporary file in /etc/config is intentional. uci is simply
using a common pattern in order to make rewriting config files atomic
and avoid leaving behind empty or incomplete files in case of a system
crash during commit.
The new file is written under a temporary name, and after a fsync, it is
renamed to the final filename. This only works if the temporary file and
the config file are on the same filesystem, that's why the temp file is
put in /etc/config as well.
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: WDS stopped working in 21.02, looking for bug in netifd
Can you please send me the config that you're using? I'd like to try to reproduce it myself. Find attached the config dumps of the AP and the client. They have been created with 21.02, but after flashing the snapshot on the AP I restored exactly this config (and the bug was still there). - D.H. backup-wds-ap.tar.gz Description: application/gzip backup-wds-client.tar.gz Description: application/gzip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: uci: unnecessary write accesses
Thanks for your feedback I have written a small shell script, to track write access to the '/etc/config' directory. For this task I am using the inotify-tool package [1]. I am using the inotifywait tool to add the watchers [2] with a small shell script and log them to the syslog. If I change a 'uci' option with the the 'uci' commands, then I get create and write events for a temporary file in the '/etc/config/' directory. I didn't expect it to be like this. For example, if I now change a file using the 'uci' command, a tmp file is created under '/etc/config'. Is this correct? Or do we have a problem there. AFAIK tmp config are written in /tmp... But if I read this correctly, what inotifywait does, then these are events that happen in '/etc/config' and not in '/tmp'. I have not added a inotify to '/tmp'. I already thought that these are temporary files. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: uci: unnecessary write accesses
>
>
> I have written a small shell script, to track write access to the
> '/etc/config' directory.
> For this task I am using the inotify-tool package [1].
> I am using the inotifywait tool to add the watchers [2] with a small
> shell script and log them to the syslog.
>
> If I change a 'uci' option with the the 'uci' commands, then I get
> create and write events for a temporary file in the '/etc/config/'
> directory.
> I didn't expect it to be like this.
>
> For example, if I now change a file using the 'uci' command, a tmp file
> is created under '/etc/config'.
> Is this correct? Or do we have a problem there.
AFAIK tmp config are written in /tmp...
> I have always thought that for embedded systems with flashes it is
> important to make as few write accesses as possible.
>
> Shell commands to change uci config:
>
> root@st-dev-07 ~ # uci set system.led_Power.trigger=none
> root@st-dev-07 ~ # uci commit system
>
> Log output of my Script:
>
> Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
> {"directory":"/etc/config/","file":".system.uci-fEGgbp","event":"CREATE","time":"09/21/21
> 12:50:38"}
> Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
> {"directory":"/etc/config/","file":".system.uci-fEGgbp","event":"MODIFY","time":"09/21/21
> 12:50:38"}
> Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
> {"directory":"/etc/config/","file":".system.uci-fEGgbp","event":"MODIFY","time":"09/21/21
> 12:50:38"}
> Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
> {"directory":"/etc/config/","file":".system.uci-fEGgbp","event":"CLOSE_WRITE,CLOSE","time":"09/21/21
> 12:50:38"}
> Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
> {"directory":"/etc/config/","file":"system","event":"CLOSE_WRITE,CLOSE","time":"09/21/21
> 12:50:38"}
> Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
> {"directory":"/etc/config/","file":".system.uci-fEGgbp","event":"ATTRIB","time":"09/21/21
> 12:50:38"}
>
> I am bothered about the file '.system.uci-fEGgbp'?
That is the tmp file (in theory)
the idea is uci set creates the tmp file
uci commit apply the tmp file to the /etc/config directory
>
>
> To do this without my script on the console, the following command can
> be used on the shell:
> inotifywait --quiet --monitor -e
> "create,delete,modify,close_write,attrib" /etc/config
>
> Then you will get the following output if you change an option with uci:
> /etc/config/ CREATE .system.uci-lOlFid
> /etc/config/ MODIFY .system.uci-lOlFid
> /etc/config/ MODIFY .system.uci-lOlFid
> /etc/config/ CLOSE_WRITE,CLOSE .system.uci-lOlFid
> /etc/config/ CLOSE_WRITE,CLOSE system
> /etc/config/ ATTRIB .system.uci-lOlFid
>
> ---
> Florian
>
> [1]
> https://github.com/openwrt/packages/blob/master/utils/inotify-tools/Makefile
> [2] https://www.man7.org/linux/man-pages/man1/inotifywait.1.html
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
uci: unnecessary write accesses
I have written a small shell script, to track write access to the
'/etc/config' directory.
For this task I am using the inotify-tool package [1].
I am using the inotifywait tool to add the watchers [2] with a small
shell script and log them to the syslog.
If I change a 'uci' option with the the 'uci' commands, then I get
create and write events for a temporary file in the '/etc/config/'
directory.
I didn't expect it to be like this.
For example, if I now change a file using the 'uci' command, a tmp file
is created under '/etc/config'.
Is this correct? Or do we have a problem there.
I have always thought that for embedded systems with flashes it is
important to make as few write accesses as possible.
Shell commands to change uci config:
root@st-dev-07 ~ # uci set system.led_Power.trigger=none
root@st-dev-07 ~ # uci commit system
Log output of my Script:
Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
{"directory":"/etc/config/","file":".system.uci-fEGgbp","event":"CREATE","time":"09/21/21
12:50:38"}
Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
{"directory":"/etc/config/","file":".system.uci-fEGgbp","event":"MODIFY","time":"09/21/21
12:50:38"}
Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
{"directory":"/etc/config/","file":".system.uci-fEGgbp","event":"MODIFY","time":"09/21/21
12:50:38"}
Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
{"directory":"/etc/config/","file":".system.uci-fEGgbp","event":"CLOSE_WRITE,CLOSE","time":"09/21/21
12:50:38"}
Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
{"directory":"/etc/config/","file":"system","event":"CLOSE_WRITE,CLOSE","time":"09/21/21
12:50:38"}
Tue Sep 21 12:50:38 2021 daemon.info loginotify[17375]:
{"directory":"/etc/config/","file":".system.uci-fEGgbp","event":"ATTRIB","time":"09/21/21
12:50:38"}
I am bothered about the file '.system.uci-fEGgbp'?
To do this without my script on the console, the following command can
be used on the shell:
inotifywait --quiet --monitor -e
"create,delete,modify,close_write,attrib" /etc/config
Then you will get the following output if you change an option with uci:
/etc/config/ CREATE .system.uci-lOlFid
/etc/config/ MODIFY .system.uci-lOlFid
/etc/config/ MODIFY .system.uci-lOlFid
/etc/config/ CLOSE_WRITE,CLOSE .system.uci-lOlFid
/etc/config/ CLOSE_WRITE,CLOSE system
/etc/config/ ATTRIB .system.uci-lOlFid
---
Florian
[1]
https://github.com/openwrt/packages/blob/master/utils/inotify-tools/Makefile
[2] https://www.man7.org/linux/man-pages/man1/inotifywait.1.html
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: WDS stopped working in 21.02, looking for bug in netifd
On 2021-09-20 22:56, Daniel Haid wrote: > Felix, I took the last openwrt snapshot and compiled netifd from master > with your patch applied and installed it. > > Result: > After boot wlan0.sta1 was DOWN. > After "/etc/init.d/network restart" it was UP and the connection worked! > After another "/etc/init.d/network restart" it was DOWN again. > After reboot it was UP again and working. > After "/etc/init.d/network restart" it was DOWN again. Can you please send me the config that you're using? I'd like to try to reproduce it myself. Thanks, - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
