Re: [OpenWrt-Devel] procd/inittab with a delayed console
Hello Owen,
I was wondering, is the kernel driver for your console not placed in
/etc/modules-boot.d ?
/sbin/init executes procd, but prior to doing this executes kmodloader
to load all modules in /etc/modules-boot.d. If your module is mentioned
in this directory, this should load your console driver, thus making it
available before procd checks /etc/inittab.
This, to me, seems the most logical solution, as consoles should be
available to the init process early on during boot, and not hot-plugged
in afterwards. Do you agree?
To put modules in /etc/modules-boot.d, make sure that their
KernelPackage definition contains:
AUTOLOAD:=$(call AutoLoad,,,1)
Where is the load order and is the name of your kernel
module (or modules). The presence of the ,1 argument indicates whether
the module is placed in /etc/modules-boot.d or /etc/modules.d.
Kind regards,
Michel Stam
Embedded System Engineer
--- Begin Message ---
Hi,
I'm not sure if this is a bug with procd's implementation of inittab or
if I'm just doing something wrong in my inittab. However, we have a
board that has multiple serial console ports, one of which relies on a
kernel module and procd refuses to start a console on the second port.
What seems to be happening is that procd loads inittab before the kernel
modules are loaded, therefore the tty device doesn't exist yet and the
check for dev_exist() fails and procd never forks a worker for that console.
I was able to fix it for my board with the following patch, but I'm not
sure if this is would be the entire fix for the problem since it seems
like fork_worker() should be a little more graceful in handling tty
devices that don't exist yet.
Any thoughts or suggestions on better ways to fix this?
Thanks,
Owen
diff --git a/inittab.c b/inittab.c
index 2efbf4d..7b12e10 100644
--- a/inittab.c
+++ b/inittab.c
@@ -161,7 +161,7 @@ static void askfirst(struct init_action *a)
{
int i;
- if (!dev_exist(a->id) || (console && !strcmp(console, a->id))) {
+ if (console && !strcmp(console, a->id)) {
DEBUG(4, "Skipping %s\n", a->id);
return;
}
--
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3] mac80211: remove error from detect script
Hello Bastian,
I saw the patch already went into GIT, so reworking it will be a tad
difficult.
Renaming from dev to phy might be tricky as phy is a non-local variable.
_phy / _dev could become local variables without problem, but to commit
a new patch just for that seems a bit unnecessary.
Kind regards,
Michel Stam
-Original Message-
From: Bastian Bittorf [mailto:bitt...@bluebottle.com]
Sent: Thursday, October 09, 2014 11:26 AM
To: Stam, Michel [FINT]
Cc: openwrt-de...@openwrt.org
Subject: Re: [OpenWrt-Devel] [PATCH v3] mac80211: remove error from
detect script
* Michel Stam [09.10.2014 11:16]:
> Signed-off-by: Michel Stam
> ---
> package/kernel/mac80211/files/lib/wifi/mac80211.sh | 15
+++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/package/kernel/mac80211/files/lib/wifi/mac80211.sh
b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
> index a3b2199..0b662eb 100644
> --- a/package/kernel/mac80211/files/lib/wifi/mac80211.sh
> +++ b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
> @@ -19,9 +19,11 @@ lookup_phy() {
>
> local macaddr="$(config_get "$device" macaddr | tr 'A-Z' 'a-z')"
> [ -n "$macaddr" ] && {
> - for _phy in $(ls /sys/class/ieee80211 2>/dev/null); do
> - [ "$macaddr" = "$(cat
/sys/class/ieee80211/${_phy}/macaddress)" ] || continue
> - phy="$_phy"
> + for _phy in /sys/class/ieee80211/*; do
> + [ -e "$_phy" ] || continue
> +
> + [ "$macaddr" = "$(cat ${_phy}/macaddress)" ] ||
continue
> + phy="${_phy##*/}"
> return
> done
> }
looks good.
> @@ -65,7 +67,12 @@ detect_mac80211() {
> [ -n "$type" ] || break
> devidx=$(($devidx + 1))
> done
> - for dev in $(ls /sys/class/ieee80211); do
> +
> + for _dev in /sys/class/ieee80211/*; do
> + [ -e "$_dev" ] || continue
> +
> + dev="${_dev##*/}"
> +
> found=0
> config_foreach check_mac80211_device wifi-device
> [ "$found" -gt 0 ] && continue
while you are at it:
please rename 'dev' to 'phy' because this is what you are searching for.
also make the var 'local'.
bye, bastian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] mac80211: remove error from detect script
Good one Felix,
I'll fix that and re-post.
Kind regards,
Michel Stam
-Original Message-
From: Felix Fietkau [mailto:n...@openwrt.org]
Sent: Wednesday, October 08, 2014 19:07 PM
To: Stam, Michel [FINT]; openwrt-devel@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] [PATCH v2] mac80211: remove error from
detect script
On 2014-10-08 15:54, Michel Stam wrote:
> Signed-off-by: Michel Stam
> ---
> package/kernel/mac80211/files/lib/wifi/mac80211.sh | 15
+++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/package/kernel/mac80211/files/lib/wifi/mac80211.sh
b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
> index a3b2199..a1ed6f6 100644
> --- a/package/kernel/mac80211/files/lib/wifi/mac80211.sh
> +++ b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
> @@ -19,9 +19,11 @@ lookup_phy() {
>
> local macaddr="$(config_get "$device" macaddr | tr 'A-Z' 'a-z')"
> [ -n "$macaddr" ] && {
> - for _phy in $(ls /sys/class/ieee80211 2>/dev/null); do
> - [ "$macaddr" = "$(cat
/sys/class/ieee80211/${_phy}/macaddress)" ] || continue
> - phy="$_phy"
> + for _phy in /sys/class/ieee80211/*; do
> + [ -e "$_phy" ] || continue
> +
> + phy="${_phy##*/}"
> + [ "$macaddr" = "$(cat
/sys/class/ieee80211/${phy}/macaddress)" ] || continue
This ends up setting $phy, even if the mac address does not match.
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] mac80211: remove error from detect script
After looking at the ticket with the rejected patch, I reimplemented the
patch using the for loop Jow suggested.
I found another line in the same file doing the ls /sys/class/ieee80211
2>/dev/null which I had used, so I rewrote that one as well.
Kind regards,
Michel Stam
-Original Message-
From: Michel Stam [mailto:m.s...@fugro.nl]
Sent: Wednesday, October 08, 2014 15:54 PM
To: openwrt-devel@lists.openwrt.org
Cc: j...@openwrt.org; blo...@openwrt.org; Stam, Michel [FINT]
Subject: [PATCH v2] mac80211: remove error from detect script
Signed-off-by: Michel Stam
---
package/kernel/mac80211/files/lib/wifi/mac80211.sh | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/package/kernel/mac80211/files/lib/wifi/mac80211.sh
b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
index a3b2199..a1ed6f6 100644
--- a/package/kernel/mac80211/files/lib/wifi/mac80211.sh
+++ b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
@@ -19,9 +19,11 @@ lookup_phy() {
local macaddr="$(config_get "$device" macaddr | tr 'A-Z' 'a-z')"
[ -n "$macaddr" ] && {
- for _phy in $(ls /sys/class/ieee80211 2>/dev/null); do
- [ "$macaddr" = "$(cat
/sys/class/ieee80211/${_phy}/macaddress)" ] || continue
- phy="$_phy"
+ for _phy in /sys/class/ieee80211/*; do
+ [ -e "$_phy" ] || continue
+
+ phy="${_phy##*/}"
+ [ "$macaddr" = "$(cat
/sys/class/ieee80211/${phy}/macaddress)" ] || continue
return
done
}
@@ -65,7 +67,12 @@ detect_mac80211() {
[ -n "$type" ] || break
devidx=$(($devidx + 1))
done
- for dev in $(ls /sys/class/ieee80211); do
+
+ for _dev in /sys/class/ieee80211/*; do
+ [ -e "$_dev" ] || continue
+
+ dev="${_dev##*/}"
+
found=0
config_foreach check_mac80211_device wifi-device
[ "$found" -gt 0 ] && continue
--
1.7.12.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH procd] Add ctrlaltdel handler to procd
I just had a thought-
Is it possible to move grabbing the SIGINT from uloop_run( ) to
uloop_init( ), with the possibility to execute a
uloop_call_this_to_end_loop() function which sets the uloop_cancelled
variable? (this could then be called from a signal handler without
exposing the uloop_cancelled variable).
The signal handler can be hooked by default by uloop to emulate existing
behaviour if that is so desired, but by taking things out of uloop_run(
) it is possible to grab back SIGINT in a nice way.
Let me know, I can rework the patches to get this to work again, but I
think its wiser to discuss this first, then implement it.
Kind regards,
Michel Stam
-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
Behalf Of Stam, Michel [FINT]
Sent: Tuesday, October 07, 2014 17:08 PM
To: openwrt-devel@lists.openwrt.org; John Crispin
Subject: Re: [OpenWrt-Devel] [PATCH procd] Add ctrlaltdel handler to
procd
Hello John,
I saw you had reworked my ctrl-alt-del patch for procd. Ok, but
unfortunately, it does not work for me.
What happens; when I press ctrl-alt-del on the unit, I get an
"attempting to kill init" panic.
This happens because the procd process exits. The kernel does not like
its init process dying.
If I look in procd.c, I see:
uloop_run();
uloop_done();
if (getpid() == 1) {
procd_shutdown(RB_AUTOBOOT);
}
procd_shutdown( ) is called, I see this on the console. But it
indirectly fires off a runqueue which should be handled from the
uloop_run( ) call. This takes care of running the shutdown scripts. But
the uloop has already been cleaned up by uloop_done( ), because the
uloop_run( ) was interrupted by the SIGINT.
Thus this runqueue is never handled. Because of this, its rcdone( ) is
never called (inittab.c), which should invoke procd_state_next( ), which
then moves procd into killing the processes and calling the reboot( )
system call.
It is important that procd does not exit before the reboot( ) system
call is called thus remaining in the uloop_run( ) and letting the loop
run its course, but without grabbing SIGINT back from libubox/uloop, I
would have no idea how to fix this.
My fix, by adding something to libubox to unhook SIGINT so the
application can catch it was not pretty, but it did solve this problem.
Another problem would be adding a process which grabs SIGINT back from
uloop( ) but this sounds a bit hackish to me.
Any suggestions?
I have finished the /proc/cmdline patch, but I'm hanging on to it as
testing my terminal fix is a tad difficult if I can't get the reboot
working properly.
Michel Stam
-Original Message-
From: Michel Stam [mailto:m.s...@fugro.nl]
Sent: Thursday, October 02, 2014 14:51 PM
To: openwrt-devel@lists.openwrt.org
Cc: Stam, Michel [FINT]
Subject: [PATCH procd] Add ctrlaltdel handler to procd
Procd, up until now, did not support the ctrlaltdel handler. Thus, the
system would immediately reboot upon the three-finger salute, and no
shutdown scripts would be run. This patch adds the handler for the
/etc/inittab entry, so that /sbin/reboot can be run and in turn the
shutdown scripts can be invoked.
Signed-off-by: Michel Stam
---
procd.c | 1 +
signal.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/procd.c b/procd.c
index ad80284..6ec7cd0 100644
--- a/procd.c
+++ b/procd.c
@@ -62,6 +62,7 @@ int main(int argc, char **argv)
}
}
uloop_init();
+ uloop_release_sigint();
procd_signal();
trigger_init();
if (getpid() != 1)
diff --git a/signal.c b/signal.c
index 74cabcb..6c00fd9 100644
--- a/signal.c
+++ b/signal.c
@@ -36,6 +36,7 @@ static void signal_shutdown(int signal, siginfo_t
*siginfo, void *data)
char *msg = NULL;
switch(signal) {
+ case SIGINT:
case SIGTERM:
event = RB_AUTOBOOT;
msg = "reboot";
@@ -91,4 +92,6 @@ void procd_signal(void)
sigaction(SIGHUP, &sa_dummy, NULL);
sigaction(SIGKILL, &sa_dummy, NULL);
sigaction(SIGSTOP, &sa_dummy, NULL);
+ sigaction(SIGINT, &sa_shutdown, NULL);
+ reboot(RB_DISABLE_CAD);
}
--
1.7.12.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH procd] Add ctrlaltdel handler to procd
Hello John,
I saw you had reworked my ctrl-alt-del patch for procd. Ok, but
unfortunately, it does not work for me.
What happens; when I press ctrl-alt-del on the unit, I get an
"attempting to kill init" panic.
This happens because the procd process exits. The kernel does not like
its init process dying.
If I look in procd.c, I see:
uloop_run();
uloop_done();
if (getpid() == 1) {
procd_shutdown(RB_AUTOBOOT);
}
procd_shutdown( ) is called, I see this on the console. But it
indirectly fires off a runqueue which should be handled from the
uloop_run( ) call. This takes care of running the shutdown scripts. But
the uloop has already been cleaned up by uloop_done( ), because the
uloop_run( ) was interrupted by the SIGINT.
Thus this runqueue is never handled. Because of this, its rcdone( ) is
never called (inittab.c), which should invoke procd_state_next( ), which
then moves procd into killing the processes and calling the reboot( )
system call.
It is important that procd does not exit before the reboot( ) system
call is called thus remaining in the uloop_run( ) and letting the loop
run its course, but without grabbing SIGINT back from libubox/uloop, I
would have no idea how to fix this.
My fix, by adding something to libubox to unhook SIGINT so the
application can catch it was not pretty, but it did solve this problem.
Another problem would be adding a process which grabs SIGINT back from
uloop( ) but this sounds a bit hackish to me.
Any suggestions?
I have finished the /proc/cmdline patch, but I'm hanging on to it as
testing my terminal fix is a tad difficult if I can't get the reboot
working properly.
Michel Stam
-Original Message-
From: Michel Stam [mailto:m.s...@fugro.nl]
Sent: Thursday, October 02, 2014 14:51 PM
To: openwrt-devel@lists.openwrt.org
Cc: Stam, Michel [FINT]
Subject: [PATCH procd] Add ctrlaltdel handler to procd
Procd, up until now, did not support the ctrlaltdel handler. Thus, the
system would immediately reboot upon the three-finger salute, and no
shutdown scripts would be run. This patch adds the handler for the
/etc/inittab entry, so that /sbin/reboot can be run and in turn the
shutdown scripts can be invoked.
Signed-off-by: Michel Stam
---
procd.c | 1 +
signal.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/procd.c b/procd.c
index ad80284..6ec7cd0 100644
--- a/procd.c
+++ b/procd.c
@@ -62,6 +62,7 @@ int main(int argc, char **argv)
}
}
uloop_init();
+ uloop_release_sigint();
procd_signal();
trigger_init();
if (getpid() != 1)
diff --git a/signal.c b/signal.c
index 74cabcb..6c00fd9 100644
--- a/signal.c
+++ b/signal.c
@@ -36,6 +36,7 @@ static void signal_shutdown(int signal, siginfo_t
*siginfo, void *data)
char *msg = NULL;
switch(signal) {
+ case SIGINT:
case SIGTERM:
event = RB_AUTOBOOT;
msg = "reboot";
@@ -91,4 +92,6 @@ void procd_signal(void)
sigaction(SIGHUP, &sa_dummy, NULL);
sigaction(SIGKILL, &sa_dummy, NULL);
sigaction(SIGSTOP, &sa_dummy, NULL);
+ sigaction(SIGINT, &sa_shutdown, NULL);
+ reboot(RB_DISABLE_CAD);
}
--
1.7.12.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH procd 7/8] Show the shutdown sequence on the active virtual terminal
Hey John,
Ok, I will rework the patch to use that, then repost it.
Kind regards,
Michel Stam
-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
Behalf Of John Crispin
Sent: Monday, October 06, 2014 16:46 PM
To: openwrt-devel@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] [PATCH procd 7/8] Show the shutdown
sequence on the active virtual terminal
On 06/10/2014 15:24, Stam, Michel [FINT] wrote:
> Hello John,
>
> We have a tty0 (our board happened to have an x86 processor), the
> situation is no different when you're running this with the console
> port on the serial port of a router board. The presence of the VT in
> the kernel determines if tty0 actually exists. So point taken, I had
> not taken that into account.
>
> My point is that i would like to see what is going on when I issue a
> reboot on a device. It would be logical to see that on whatever screen
> happens to be active at that moment.
> Is it acceptable for you if I try and open /dev/tty0 if available, or
> use /dev/console otherwise?
>
> Kind regards,
>
> Michel Stam
inside inittab.c we work out the value of console= on the kernels
cmdline and use the value as basis for setting up console. you could try
to reuse that value to work out actual terminal that the messages should
be printed to.
>
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of John Crispin
> Sent: Friday, October 03, 2014 18:35 PM
> To: openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH procd 7/8] Show the shutdown
> sequence on the active virtual terminal
>
> see inline
>
> On 02/10/2014 14:56, Michel Stam wrote:
>> procd by default writes to /dev/console. When rebooting, this means
>> that the terminal on which the reboot sequence was started will not
>> see what is going on. This patch fixes that by reopening stdin,
>> stdout
>
>> and stderr to /dev/tty0 upon reboot.
>>
>> Also, due to (probably) pivot-root, /proc/1/fd shows 1-3 pointing to
>> /console. This patch also fixes that.
>>
>> Signed-off-by: Michel Stam --- state.c | 13
>> + 1 file changed, 13 insertions(+)
>>
>> diff --git a/state.c b/state.c index e6c8712..2268de3 100644 ---
>> a/state.c +++ b/state.c @@ -12,7 +12,9 @@ * GNU General Public
>> License
>
>> for more details. */
>>
>> +#include #include +#include
>> #include #include #include @@
>> -37,6 +39,14 @@ enum { static int state = STATE_NONE; static int
>> reboot_event;
>>
>> +static void set_stdio( const char* tty ) +{ + freopen( tty,
> "r",
>> stdin ); + freopen( tty, "w", stdout ); + freopen( tty, "w",
> stderr
>> ); + fcntl(STDERR_FILENO, F_SETFL, fcntl(STDERR_FILENO, F_GETFL) |
>> O_NONBLOCK); +} + static void state_enter(void) { char ubus_cmd[] =
>> "/sbin/ubusd"; @@ -55,6 +65,7 @@ static void state_enter(void)
>> LOG("- ubus -\n"); procd_connect_ubus();
>>
>> +set_stdio( "/dev/console" ); LOG("- init -\n");
> service_init();
>> service_start_early("ubus", ubus_cmd); @@ -71,6 +82,8 @@ static void
>> state_enter(void) break;
>>
>> case STATE_SHUTDOWN: + /* Redirect output to the
> current virtual
>> terminal for the users' benefit */ + set_stdio( "/dev/tty0"
> );
>
> tty0 is a virtual console on a desktop. routers don't have a tty0.
> this would break all the routers
>
>
>
>> LOG("- shutdown -\n"); procd_inittab_run("shutdown"); sync();
>>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH procd 2/8] Log startup/shutdown toconsole
Ok John,
Thanks
Kind regards,
Michel Stam
-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
Behalf Of John Crispin
Sent: Monday, October 06, 2014 16:44 PM
To: openwrt-devel@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] [PATCH procd 2/8] Log startup/shutdown
toconsole
On 06/10/2014 15:12, Stam, Michel [FINT] wrote:
> Hello John,
>
> A single printf would not work; it seems to work if it is a fprintf to
> stderr. The problem with regular printfs is that if someone presses
> CTRL-S /scroll lock on the console, they can effectively block procd
> that way, because printf will block when writing to a blocked tty.
>
> Also, this would require my other patch at
> http://patchwork.openwrt.org/patch/6364/, otherwise stderr may be
> blocked as well.
>
> Please let me know if this is an acceptable solution, I will then
> rework the patch this way.
lets use 6364 + a fprintf(sdterr, "")
i will use the patches you sent as a basis and do the missing bits.
>
> Kind regards,
>
> Michel Stam
>
> -Original Message- From: openwrt-devel
> [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of John
> Crispin Sent: Friday, October 03, 2014 18:30 PM To:
> openwrt-devel@lists.openwrt.org Subject: Re: [OpenWrt-Devel] [PATCH
> procd 2/8] Log startup/shutdown toconsole
>
> stdout is already /dev/console i think and removing the messages on
> shutdown also removes them in all other cases from the log.
>
> should adding a single printf("%s", str); not work ?
>
> On 02/10/2014 14:56, Michel Stam wrote:
>> procd has the habit of logging startup/shutdown via rcS to syslog,
>> which is pointless in case of a shutdown, and unlikely to be complete
>> on a startup (as syslog is not running). Write to /dev/console
>> instead.
>>
>> Signed-off-by: Michel Stam --- rcS.c | 10
>> ++ 1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/rcS.c b/rcS.c index 4545621..e01fc49 100644 --- a/rcS.c
>> +++ b/rcS.c @@ -18,10 +18,11 @@
>>
>> #include #include
>> +#include #include #include
>> #include -
>
>> +#include #include #include
>> #include @@ -43,8 +44,9 @@ struct initd { static void
>> pipe_cb(struct ustream *s, int bytes) { char *newline, *str; -
>> int len; + int len, console_fd;
>>
>> +console_fd = open(_PATH_CONSOLE, O_WRONLY | O_NOCTTY |
>> O_NONBLOCK); do { str = ustream_get_read_buf(s, NULL); if (!str) @@
>> -52,11 +54,11 @@ static void pipe_cb(struct ustream *s, int
>> bytes) newline = strchr(str, '\n'); if (!newline) break; - *newline
> = 0;
>> len = newline + 1 - str; - syslog(0, "%s", str); +
>> write(console_fd, str, len); ustream_consume(s, len); } while
>> (1); + close(console_fd); }
>>
>> static void q_initd_run(struct runqueue *q, struct runqueue_task
>> *t)
>>
> ___ openwrt-devel mailing
> list openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> ___ openwrt-devel mailing
> list openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH procd 7/8] Show the shutdown sequence on the active virtual terminal
Hello John,
We have a tty0 (our board happened to have an x86 processor), the
situation is no different when you're running this with the console port
on the serial port of a router board. The presence of the VT in the
kernel determines if tty0 actually exists. So point taken, I had not
taken that into account.
My point is that i would like to see what is going on when I issue a
reboot on a device. It would be logical to see that on whatever screen
happens to be active at that moment.
Is it acceptable for you if I try and open /dev/tty0 if available, or
use /dev/console otherwise?
Kind regards,
Michel Stam
-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
Behalf Of John Crispin
Sent: Friday, October 03, 2014 18:35 PM
To: openwrt-devel@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] [PATCH procd 7/8] Show the shutdown
sequence on the active virtual terminal
see inline
On 02/10/2014 14:56, Michel Stam wrote:
> procd by default writes to /dev/console. When rebooting, this means
> that the terminal on which the reboot sequence was started will not
> see what is going on. This patch fixes that by reopening stdin, stdout
> and stderr to /dev/tty0 upon reboot.
>
> Also, due to (probably) pivot-root, /proc/1/fd shows 1-3 pointing to
> /console. This patch also fixes that.
>
> Signed-off-by: Michel Stam --- state.c | 13
> + 1 file changed, 13 insertions(+)
>
> diff --git a/state.c b/state.c index e6c8712..2268de3 100644 ---
> a/state.c +++ b/state.c @@ -12,7 +12,9 @@ * GNU General Public License
> for more details. */
>
> +#include #include +#include
> #include #include #include @@
> -37,6 +39,14 @@ enum { static int state = STATE_NONE; static int
> reboot_event;
>
> +static void set_stdio( const char* tty ) +{ +freopen( tty,
"r",
> stdin ); +freopen( tty, "w", stdout ); + freopen( tty, "w",
stderr
> ); + fcntl(STDERR_FILENO, F_SETFL, fcntl(STDERR_FILENO, F_GETFL) |
> O_NONBLOCK); +} + static void state_enter(void) { char ubus_cmd[] =
> "/sbin/ubusd"; @@ -55,6 +65,7 @@ static void state_enter(void)
> LOG("- ubus -\n"); procd_connect_ubus();
>
> + set_stdio( "/dev/console" ); LOG("- init -\n");
service_init();
> service_start_early("ubus", ubus_cmd); @@ -71,6 +82,8 @@ static void
> state_enter(void) break;
>
> case STATE_SHUTDOWN: +/* Redirect output to the
current virtual
> terminal for the users' benefit */ + set_stdio( "/dev/tty0"
);
tty0 is a virtual console on a desktop. routers don't have a tty0.
this would break all the routers
> LOG("- shutdown -\n"); procd_inittab_run("shutdown"); sync();
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH procd 2/8] Log startup/shutdown toconsole
Hello John,
A single printf would not work; it seems to work if it is a fprintf to
stderr. The problem with regular printfs is that if someone presses
CTRL-S /scroll lock on the console, they can effectively block procd
that way, because printf will block when writing to a blocked tty.
Also, this would require my other patch at
http://patchwork.openwrt.org/patch/6364/, otherwise stderr may be
blocked as well.
Please let me know if this is an acceptable solution, I will then rework
the patch this way.
Kind regards,
Michel Stam
-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
Behalf Of John Crispin
Sent: Friday, October 03, 2014 18:30 PM
To: openwrt-devel@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] [PATCH procd 2/8] Log startup/shutdown
toconsole
stdout is already /dev/console i think and removing the messages on
shutdown also removes them in all other cases from the log.
should adding a single printf("%s", str); not work ?
On 02/10/2014 14:56, Michel Stam wrote:
> procd has the habit of logging startup/shutdown via rcS to syslog,
> which is pointless in case of a shutdown, and unlikely to be complete
> on a startup (as syslog is not running). Write to /dev/console
> instead.
>
> Signed-off-by: Michel Stam --- rcS.c | 10
> ++ 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/rcS.c b/rcS.c index 4545621..e01fc49 100644 --- a/rcS.c
> +++ b/rcS.c @@ -18,10 +18,11 @@
>
> #include #include +#include
> #include #include #include -
> +#include #include #include
> #include @@ -43,8 +44,9 @@ struct initd { static void
> pipe_cb(struct ustream *s, int bytes) { char *newline,
> *str; - int len; + int len, console_fd;
>
> + console_fd = open(_PATH_CONSOLE, O_WRONLY | O_NOCTTY |
> O_NONBLOCK); do { str = ustream_get_read_buf(s, NULL); if (!str) @@
> -52,11 +54,11 @@ static void pipe_cb(struct ustream *s, int bytes)
> newline = strchr(str, '\n'); if (!newline) break; - *newline
= 0;
> len = newline + 1 - str; -syslog(0, "%s", str); +
> write(console_fd, str, len); ustream_consume(s, len); } while (1);
> + close(console_fd); }
>
> static void q_initd_run(struct runqueue *q, struct runqueue_task
> *t)
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH procd 3/8] Fix curses applications towork with procd
Hello Gert, After looking through the documentation and code here, I found why I implemented it this way; Several months ago we had, as mentioned before, a problem getting curses applications to start on a new version of OpenWRT. This manifested in applications not starting at all, or not accepting any input from STDIN, but otherwise outputing to STDOUT quite nicely. I then started by checking the init.c of the busybox that was used with the older OpenWRT, I believe this was busybox 1.4. This version of busybox did the ioctl I did, and as I was under time pressure, it-worked-for-me, and I added the patch. After your comment, I looked into this a little deeper, found that the ioctl was not really necessary, and removed it. It has since been removed from busybox init.c too, which only helped to convince me. I will submit this revised patch on the mailing list in a few minutes. Thanks for the remark. Kind regards, Michel Stam -Original Message- From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Stam, Michel [FINT] Sent: Friday, October 03, 2014 17:23 PM To: Gert Doering Cc: openwrt-devel@lists.openwrt.org Subject: Re: [OpenWrt-Devel] [PATCH procd 3/8] Fix curses applications towork with procd Hello Gert, Good question. What we discovered during an upgrade of our OpenWRT distribution (from a fairly old one, I cannot exactly recall the version, I do recall it was running kernel 2.6.22), was that suddenly our curses application did not start anymore. And yes, for historical reasons, it was executed from the inittab, no argument there. I was looking into the reason and typing an answer to you, but I have to look a little better as to the why. If you don't mind, I will get back to you on Monday. Kind regards, Michel Stam -Original Message- From: Gert Doering [mailto:g...@greenie.muc.de] Sent: Friday, October 03, 2014 16:16 PM To: Stam, Michel [FINT] Cc: openwrt-devel@lists.openwrt.org Subject: Re: [OpenWrt-Devel] [PATCH procd 3/8] Fix curses applications to work with procd Hi, On Thu, Oct 02, 2014 at 02:56:18PM +0200, Michel Stam wrote: > The problem was caused by procd not opening /dev/tty* (which ever was > specified in /etc/inittab), causing /proc/PID/fd to point to /console > instead. /dev/console is a non-controlling tty (CTTY), and cannot be > used as one, which is exactly what curses applications want. Since > this is very likely to cause problems with other programs, procd now > opens /dev/tty? when the ID field of the inittab assigns one, and forces this to be a CTTY. I won't claim to understand the OpenWRT intricacies here, so take this with a grain of salt. In traditional unix systems, setting up a tty and acquiring a controlling tty is getty's job, and not that of the init system - and init should not start interactive programs (or "possibly interactive programs") from /etc/inittab. Changing this is fairly invasive into the way the system works and what programs can expect regarding signal delivery etc. - like, someone pressing ctrl-c on a tty, and a background process being started on that tty will get a SIGINT (while it normally wouldn't). Genuinely curious: can you explain a bit better in which cases this change would be needed and/or beneficial? thanks, gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] mac80211: remove error from detectscript
Hello Jo,
I answered John, without realising that you described a similar use
case.
The for loop as you describe should solve the problem as well.
Kind regards,
Michel Stam
-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
Behalf Of Jo-Philipp Wich
Sent: Friday, October 03, 2014 19:37 PM
To: openwrt-devel@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] [PATCH] mac80211: remove error from
detectscript
Hi Michel, John.
>> -for dev in $(ls /sys/class/ieee80211); do
>> +for dev in $(ls /sys/class/ieee80211 2>/dev/null); do
> what error do you see ? if you see an error we should try to fix that
> rather than supressing it
I suppose the case when "wifi detect" is invoked but no phy exists on
the system (e.g. because the radio hardware is not installed - think
USB).
In this case the entire /sys/class/ieee80211 is likely missing which
will cause "ls" to print a "No such file or directory" error.
Actually I do not really like that whole "for x in $(ls ...)" construct,
something like the following would save one fork and also not produce
errors:
for dev in /sys/class/ieee80211/*; do
if [ -h "$dev" ]; then
# do something with ${dev##*/}
fi
done
~ Jow
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] mac80211: remove error from detectscript
Hello John,
The error that I see is that the directory does not exist. This happens
when the unit does not have a ieee80211 card available, or if the
kernel does not have wifi suppor. In both cases, /sys/class/ieee80211
does not exist and the script echoes an error to the screen that does
not really indicate a problem.
In our particular case, it was discovered on a unit that can be shipped
with and without WiFi. So depending on the presence of the hardware,
this error appears. Since the error is not relevant, redirecting stderr
to /dev/null will cause the ls to return '', which causes the shell
script to not do anything in the for loop. Nothing will be done by the
mac80211.sh script, and the system continues as normal.
Kind regards,
Michel Stam
-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
Behalf Of John Crispin
Sent: Friday, October 03, 2014 19:32 PM
To: openwrt-devel@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] [PATCH] mac80211: remove error from
detectscript
On 02/10/2014 15:28, Michel Stam wrote:
> Signed-off-by: Michel Stam
> ---
> package/kernel/mac80211/files/lib/wifi/mac80211.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/package/kernel/mac80211/files/lib/wifi/mac80211.sh
> b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
> index a3b2199..2af4dc5 100644
> --- a/package/kernel/mac80211/files/lib/wifi/mac80211.sh
> +++ b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
> @@ -65,7 +65,7 @@ detect_mac80211() {
> [ -n "$type" ] || break
> devidx=$(($devidx + 1))
> done
> - for dev in $(ls /sys/class/ieee80211); do
> + for dev in $(ls /sys/class/ieee80211 2>/dev/null); do
what error do you see ? if you see an error we should try to fix that
rather than supressing it
> found=0
> config_foreach check_mac80211_device wifi-device
> [ "$found" -gt 0 ] && continue
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH procd 3/8] Fix curses applications to work with procd
Hello Gert, Good question. What we discovered during an upgrade of our OpenWRT distribution (from a fairly old one, I cannot exactly recall the version, I do recall it was running kernel 2.6.22), was that suddenly our curses application did not start anymore. And yes, for historical reasons, it was executed from the inittab, no argument there. I was looking into the reason and typing an answer to you, but I have to look a little better as to the why. If you don't mind, I will get back to you on Monday. Kind regards, Michel Stam -Original Message- From: Gert Doering [mailto:g...@greenie.muc.de] Sent: Friday, October 03, 2014 16:16 PM To: Stam, Michel [FINT] Cc: openwrt-devel@lists.openwrt.org Subject: Re: [OpenWrt-Devel] [PATCH procd 3/8] Fix curses applications to work with procd Hi, On Thu, Oct 02, 2014 at 02:56:18PM +0200, Michel Stam wrote: > The problem was caused by procd not opening /dev/tty* (which ever was > specified in /etc/inittab), causing /proc/PID/fd to point to /console > instead. /dev/console is a non-controlling tty (CTTY), and cannot be > used as one, which is exactly what curses applications want. Since > this is very likely to cause problems with other programs, procd now > opens /dev/tty? when the ID field of the inittab assigns one, and forces this to be a CTTY. I won't claim to understand the OpenWRT intricacies here, so take this with a grain of salt. In traditional unix systems, setting up a tty and acquiring a controlling tty is getty's job, and not that of the init system - and init should not start interactive programs (or "possibly interactive programs") from /etc/inittab. Changing this is fairly invasive into the way the system works and what programs can expect regarding signal delivery etc. - like, someone pressing ctrl-c on a tty, and a background process being started on that tty will get a SIGINT (while it normally wouldn't). Genuinely curious: can you explain a bit better in which cases this change would be needed and/or beneficial? thanks, gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files: remove a 'not found' error message during system boot
Hello Jo, I was not aware of this option, must have overlooked it. I will fix the patch and resubmit it. Kind regards, Michel Stam ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/3] busybox: allow own class B range to be used for zeroconf
Hey Felix, I've already done this. My intention was to submit it to both OpenWRT and Busybox, then add another commit to remove the patch once it is in a busybox release. See here: OpenWRT commit -> busybox ticket busybox/netifd: make zcip log to syslog (always) -> https://bugs.busybox.net/show_bug.cgi?id=7502 busybox: allow own class B range to be used for zeroconf -> https://bugs.busybox.net/show_bug.cgi?id=7496 busybox: add option for tweaking arpping to udhcpd -> https://bugs.busybox.net/show_bug.cgi?id=7490 Kind regards, Fugro Intersite B.V. Michel Stam Embedded System Engineer T +31 (0)70 31 70575 | F +31 (0)70 31 11890 m.s...@fugro.nl | www.fugro.com Dillenburgsingel 69, 2263 HW Leidschendam | P.O. Box 154, 2260 AD Leidschendam, The Netherlands Trade Register nr 34048179 | VAT nr NL005621409B24 -Original Message- From: Felix Fietkau [mailto:n...@openwrt.org] Sent: Friday, October 03, 2014 0:04 AM To: Stam, Michel [FINT]; openwrt-devel@lists.openwrt.org Subject: Re: [OpenWrt-Devel] [PATCH 2/3] busybox: allow own class B range to be used for zeroconf On 2014-10-02 15:41, Michel Stam wrote: > 169.254 may be used by local networks. This patch allows specifying > your own IP range. > > Signed-off-by: Michel Stam Could you please also submit this and the other patch to busybox upstream? Thanks, - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH ubox] Use different loglevels
Hey Karl,
I agree that verbose in the macro would be an option, although by then
you're re-implementing the syslog priorities in macros.
Also, currently the verbose argument is only used in deps_available( ),
which would mean implementing the verbose parameter throughout the
kmodloader.c source. As said, not the most difficult to do, but what
would it gain?
Let me know.
Regards,
Michel Stam
-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On
Behalf Of Karl P
Sent: Thursday, October 02, 2014 16:03 PM
To: openwrt-devel@lists.openwrt.org
Subject: Re: [OpenWrt-Devel] [PATCH ubox] Use different loglevels
Just one minor inline,
Cheers,
Karl P
On 10/02/2014 12:42 PM, Michel Stam wrote:
> Ubox logs various messages during OpenWRT boot which are not very
> interesting, such as the number of iterations made. This fix
> implements several loglevels for debug/info/error so that more useful
> messages are shown.
>
> Signed-off-by: Michel Stam
> ---
> kmodloader.c | 75
+---
> 1 file changed, 41 insertions(+), 34 deletions(-)
>
> diff --git a/kmodloader.c b/kmodloader.c index 633570f..04d7c1d 100644
> --- a/kmodloader.c
> +++ b/kmodloader.c
> @@ -38,10 +38,17 @@
>
> #define DEF_MOD_PATH "/lib/modules/%s/"
>
> -#define LOG(fmt, ...) do { \
> +#define INFO(fmt, ...) do { \
> syslog(LOG_INFO, fmt, ## __VA_ARGS__); \
> printf("kmod: "fmt, ## __VA_ARGS__); \
> } while (0)
> +#define ERROR(fmt, ...) do { \
> + syslog(LOG_ERR, fmt, ## __VA_ARGS__); \
> + fprintf(stderr,"kmod: "fmt, ## __VA_ARGS__); \
> + } while (0)
> +#define DEBUG(fmt, ...) do { \
> + syslog(LOG_DEBUG, fmt, ## __VA_ARGS__); \
> + } while (0)
>
>
> enum {
> @@ -165,7 +172,7 @@ static int elf_find_section(char *map, const char
*section, unsigned int *offset
> else if (clazz == ELFCLASS64)
> return elf64_find_section(map, section, offset, size);
>
> - LOG("unknown elf format %d\n", clazz);
> + ERROR("unknown elf format %d\n", clazz);
>
> return -1;
> }
> @@ -208,7 +215,7 @@ static int scan_loaded_modules(void)
>
> fp = fopen("/proc/modules", "r");
> if (!fp) {
> - LOG("failed to open /proc/modules\n");
> + ERROR("failed to open /proc/modules\n");
> return -1;
> }
>
> @@ -243,23 +250,23 @@ static struct module* get_module_info(const char
*module, const char *name)
> struct stat s;
>
> if (!fd) {
> - LOG("failed to open %s\n", module);
> + ERROR("failed to open %s\n", module);
> return NULL;
> }
>
> if (fstat(fd, &s) == -1) {
> - LOG("failed to stat %s\n", module);
> + ERROR("failed to stat %s\n", module);
> return NULL;
> }
>
> map = mmap(NULL, s.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
> if (map == MAP_FAILED) {
> - LOG("failed to mmap %s\n", module);
> + ERROR("failed to mmap %s\n", module);
> return NULL;
> }
>
> if (elf_find_section(map, ".modinfo", &offset, &size)) {
> - LOG("failed to load the .modinfo section from %s\n",
module);
> + ERROR("failed to load the .modinfo section from %s\n",
module);
> return NULL;
> }
>
> @@ -329,23 +336,23 @@ static int print_modinfo(char *module)
> char *map, *strings;
>
> if (!fd) {
> - LOG("failed to open %s\n", module);
> + ERROR("failed to open %s\n", module);
> return -1;
> }
>
> if (fstat(fd, &s) == -1) {
> - LOG("failed to stat %s\n", module);
> + ERROR("failed to stat %s\n", module);
> return -1;
> }
>
> map = mmap(NULL, s.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
> if (map == MAP_FAILED) {
> - LOG("failed to mmap %s\n", module);
> + ERROR("failed to mmap %s\n", module);
> return -1;
> }
>
> if (elf_find_section(map, ".modinfo", &offset, &size)) {
> - LOG("failed to load the .modinfo section from %s\n",
module);
> + ERROR("failed to load the .modinfo section from %s\n",
module);
> return -1;
> }
>
> @@ -390,9 +397,9 @@ static int deps_available(struct module *m, int
verbose)
> m = find_module(dep);
>
> if (verbose && !m)
> - LOG("missing dependency %s\n", dep);
> + ERROR("missing dependency %s\n", dep);
> if (verbose && m && (m->state != LOADED))
> - LOG("dependency not loaded %s\n", dep);
> + ERROR("dependency not loaded %s\n", dep);
> if (!m || (m->state != LOADED))
> err++;
Would it make sense to maybe move the verbose checks into the log levels
themselves?
> dep += strlen(dep
