pending patches

[Vladimir Dronnikov]

> http://drvv.ru/busybox/sv.patch
>
> I don't like this, but ok. Applied.


I'll explain why I need it. I use totally volatile /var. My services are in
/etc, under which I place all scripts. We have config option for udhcpc
helper script location -- we now have configurable root of services. Thanks!

http://drvv.ru/busybox/httpd.patch
>
> Bug - cur->after_colon is leaked:
> -               cur->after_colon = strchr(cur->before_colon, ':');
> -               *cur->after_colon++ = '\0';
> +               cur->after_colon = xstrdup(token[1]);


Will revisit.

http://drvv.ru/busybox/rdev.patch
>
> This would be an incompatible change to rdev applet.
> I don't want to do this...


Could we then add -n option to mountpoint which would print the name of
block device a directory is mounted on?
Bernhard asked the mountpoint' author -- no reply AFAIK...

http://drvv.ru/busybox/acpid.patch
>
> +       argv += optind;
> +       // daemonize unless -d given
> +       if (!(option_mask32 & 1)) { // ! -d
> +               forkexit_or_rexec(argv);
>
> (1) argv is wrong here, you did argv += optind too early.


Right.

(2) forkexit_or_rexec() in general is an internal function.
>     Use bb_daemonize_or_rexec() instead, it does this and
>     also all of the below...
>
> +               setsid();
> +               // close 0, 1?
> +               // ?
> +               // reopen stderr
> +               freopen(opt_logfile, "w", stderr);
> +       }


I don't want /dev/null to be my stderr. bb_daemonize_or_rexec() would do
unnecessary things here.

but more importantly, why daemonizing at all? This works:
> setsid acpid ... </dev/null >/dev/null 2>somewhere &



We daemonize in inetd et.al. only because that is
> their historical behavior... is daemonization something
> you need for compat reasons?


Personally, I use acpid as runit service. Daemonizing was requested as it is
"default behaviour of big brother". I'd throw away intrinsic daemonizing if
you support me.


> +               for (i = 0; i < argc; i++) {
> +                       pfd[nfd].fd = open_or_warn(argv[i], O_RDONLY);
> +                       pfd[nfd].events = POLLIN;
> +                       nfd++;
> +               }
>
> if open fails, you probably do not want to use fd == -1
> in poll()?


Surely no :)

+               while (!bb_got_signal && safe_poll(pfd, nfd, -1) > 0) {
>
> safe_poll() will loop on EINTR. Thus SIGINT will not interrupt it,
> it may sit like this forever.


It is intended to be SIGTERMed to exit. As other services do.

+config ACPID
> +       bool "acpid"
> +       default n
> +       select RUN_PARTS  <=====
>
> Using run-parts does not mean you must force user to have run-parts
> applet *in the same binary*.


Right. It is just a hint. Sorry, I'm trying to BBify everyone and everything
:)

http://drvv.ru/busybox/mailutils.patch
>
> Applied, since sendmail-related applets are "yours". :)


Great! Thanks! Let us test it.
--
Vladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20081107/dd9b81e0/attachment-0002.htm