gmane.linux.busybox

Re: [PATCH] init: handle kexec clean reboot

Harald Becker — 2013-05-23T03:47:29

Hi Laurent !


Yes! After activating brain I got to same.

init shall create a named pipe (fifo, e.g. /dev/init) and held
open the read end of the pipe. As soon as data is available on
this pipe init shall stop normal processing and exec to restart
action/script with the read end of the pipe on stdin of the
script.

To shutdown the system we have to write the type of shutdown to
the fifo. The script can read this info and determine action. One
solution for unlimited number of clean shutdown cases. No need to
have init do any other shutdown action. Everything controlled by
final script.

halt/reboot/poweroff without -f just write single character "H" /
"R" / "P" followed by a newline to fifo. May be extended to any
number of cases without need to add anything further to init.
script may even restart init and resume normal operation after
doing some processing.

This is just a suggestion. The easy and extendable way I think.

--
Harald

Re: [PATCH] init: handle kexec clean reboot

Rob Landley — 2013-05-23T03:09:36

It was designed that wasy because you have to tell init to stop  
respawning services. (You've always been able to do reboot -f yourself  
if you don't actually care.)

Rob

Re: [PATCH] init: handle kexec clean reboot

Laurent Bercot — 2013-05-23T01:58:05

 It is still necessary to have some minimal hook in init, so that
init stops monitoring processes during the shutdown procedure.

New shell command: prlimit

Joshua Judson Rosen — 2013-05-23T02:53:42

The attached patch adds a new shell builtin, "prlimit", which is similar
to ulimit but can operate on any process (not just the current process),
by using Linux's prlimit() function.

prlimit takes a PID as a first argument, and then processes the rest of
its arguments identically to ulimit, e.g.:

prlimit 3431 -c unlimited

Maybe this is of general interest?

Re: [PATCH] init: handle kexec clean reboot

Harald Becker — 2013-05-23T02:28:24

Hi Laurent !


Nobody can know everything!


Remember: killall5 is SYSV not Linux, so process scanning is
historical and no more required on Linux. 


Sounds much like the way I'm doing shutdown ... :)

IMO we shall make things more easy and not add more cases to the
init shutdown process.


To grab Laurent's idea: What about a separate shutdown applet in
Busybox:

kill(-1,TERM), sleep, kill(-1,KILL), sleep, umount, sync then
exec into the given remainder of command line? And remove all
special shutdown processing from init process?

Vor easy shutdown we can do: shutdown poweroff -f
... or: shutdown kexec whatever

... and, as Denys tend to have things compatible to upstream
utilities: Busybox is already different on it's init system. Why
not going one step further and making it simpler.

--
Harald

Re: [PATCH] init: handle kexec clean reboot

Laurent Bercot — 2013-05-23T00:42:12

 Indeed, I'm used to the POSIX specification and should read the
Linux man pages more often... thanks Harald.

 And if the killing process does not kill itself, then there is no
reason at all for process scanning, and the killall5 insanity is
totally unnecessary.
 Only a "killall-and-exec" program is needed, which performs
kill(-1, SIGKILL) and execs into the remainder of the command line.
This command line can be the last part of a shutdown script - it
can be a script itself, unmounting the filesystems and powering off
the machine.

Re: [PATCH] init: handle kexec clean reboot

Harald Becker — 2013-05-23T01:36:07

Hi Laurent !


See "man 2 kill" and scroll down to the notes. kill(-1,sig) does
not send to calling process on Linux. Linux specific not POSIX.

--
Harald

[PATCH] date: accept 'yyyy-mm-dd HH' and 'yyyy-mm-dd' date formats.

Bartosz Golaszewski — 2013-05-22T20:52:59

This makes busybox date more compatible with coreutils and fixes a TODO
in libbb/time.c.

Signed-off-by: Bartosz Golaszewski <bartekgola< at >gmail.com>
---
 libbb/time.c |   16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/libbb/time.c b/libbb/time.c
index 57e14b6..3d8305d 100644
--- a/libbb/time.c
+++ b/libbb/time.c
< at >< at > -58,7 +58,6 < at >< at > void FAST_FUNC parse_datestr(const char *date_str, struct tm *ptm)
 return; /* don't fall through to end == ":" check */
 } else
 #endif
-//TODO: coreutils 6.9 also accepts "yyyy-mm-dd HH" (no minutes)
 {
 bb_error_msg_and_die(bb_msg_invalid_date, date_str);
 }
< at >< at > -68,7 +67,20 < at >< at > void FAST_FUNC parse_datestr(const char *date_str, struct tm *ptm)
 end = '\0';
 /* else end != NUL and we error out */
 }
-} else if (date_str[0] == '< at >') {
+} else
+/* yyyy-mm-dd HH */
+if ((sscanf(date_str, "%u-%u-%u %u%c", &ptm->tm_year,
+&ptm->tm_mon, &ptm->tm_mday,
+&ptm->tm_hour, &end) >= 4) ||
+/* yyyy-mm-dd */
+(sscanf(date_str,

Re: [PATCH] init: handle kexec clean reboot

Laurent Bercot — 2013-05-22T17:41:11

 Follow-up. Sorry for the spam.
 So, as I expected, killall5 is a heavy monster, scanning the process
list in /proc (so, not portable), and killing them one by one unless
they match some criteria. Absolutely ugly, needs some specific tweaks
to support FUSE, and would exhibit a huge race condition if it didn't
SIGSTOP all processes before scanning and SIGCONT them after killing.

 Definitely not the kind of program you'd want your daughter to hang
around with. I'll stay with my "perform the kill in process 1" routine,
it's a lot faster (only 1 system call) and much less ad-hoc and kludgy.

 Something is still puzzling me though: to stop all processes before the
scan, killall5 performs kill(-1, SIGSTOP).
 How does it not stop itself ? You're not supposed to be able to ignore
SIGSTOP, and although sysvinit killall5 ignores it anyway (yay more
useless system calls), busybox killall5 does not and still works - I'd
assume.
 There's no comment about this in either sysvinit or busybox, and I have
been unable to fin

Re: [PATCH] init: handle kexec clean reboot

Laurent Bercot — 2013-05-22T17:01:00

 Erratum: killall5 prevents this, since it does not signal the processes
in its own session. Ugh. I'll have to study how it's done - the kill()
system call does not make this easy, so I suspect excluding one process
group or session from the slaughter requires scanning. Brb studying this.

Re: [PATCH] init: handle kexec clean reboot

Laurent Bercot — 2013-05-22T16:53:23

 You are forgetting two things ;)

 1. Supervision systems rooted in process 1 - including sysvinit and
busybox init - automatically restart one or more processes when they
die, which is a good thing since it guarantees that the machine will
always be in a usable state (provided supervised services are properly
configured).
 Automatically restarted processes might prevent filesystem unmounting.
So, before killing everything manually to shut down the OS, it is
necessary to disable supervision. If the supervision chain is rooted in
process 1 as it should be, this can only be done by signalling process 1
in some way.

 2. Your manual shutdown script will kill itself when it sends SIGKILL
to everyone, and will not complete. The only way to prevent that is to
run the shutdown procedure as process 1 - or at least to have a hook in
process 1 to run the remaining shutdown script after the kill.

 Manually shutting down works in your example because you have a shell
running as process 1, which 1. provides no supervi

Re: [PATCH] init: handle kexec clean reboot

Denys Vlasenko — 2013-05-22T16:42:30

I think the entire "reboot/shutdown through init" idea
is not too clever invention in general.

The operation of shutting down the system
is not intrinsically tied to init.

Imagine that you was given a root shell prompt
at the Unix-like machine and instructed to shut it down
as cleanly as possible, without looking at ps output
and without assuming which type of init system is used
(it may as well use a custom, non-standard init process).

What would you do?

I'd do something like:

cd /
killall5 -TERM
sleep <SMALLNUM>
killall5 -KILL
sleep <SMALLNUM>
umount -a -r
sync
poweroff -f   # says directly to kernel: "physically power off the box please"

See? This requires no communication with init, or
knowledge about other running processes: Unix programs
*have to* shutdown on SIGTERM, with a very few exceptions.
Bad boys will be dealt with SIGKILL anyway.

You can perform kexec the same way.

--
vda

Re: Ntpd: bug and patch: not reporting lost sync

Denys Vlasenko — 2013-05-22T16:19:29

I will add something like this in main loop:


                if (G.ntp_peers && G.stratum != MAXSTRAT) {
                        for (item = G.ntp_peers; item != NULL; item =
item->link) {
                                peer_t *p = (peer_t *) item->data;
                                if (p->p->reachable_bits)
                                        goto have_reachable_peer;
                        }
                        /* No peer responded for last 8 packets, panic */
                        G.polladj_count = 0;
                        G.poll_exp = MINPOLL;
                        G.stratum = MAXSTRAT;
                        run_script("unsync", G.last_update_offset);
 have_reachable_peer: ;
                }
        } /* while (!bb_got_signal) */

and the script can look for unsync event.

Re: [PATCH] init: handle kexec clean reboot

Harald Becker — 2013-05-22T05:17:45

Hi Denys !


I started working with Unix like systems at the end of the 1980s
and worked on big Machines like Data General, Honeywell Bull
down to small process controlling machines. On many of those
machines either a RUNLEVEL like information is used to determine
type of system shutdown or an information passed outside the init
process.

I do not know if there are standards on how to do this. It is
just what I found to be used on many systems.


Using files on shared memory is newer practice and not so
problematic as you may assume. /etc/fstab knows about a mount
parameter called auto. Only those file systems are
mounted/umounted in an automatic process. Other systems may be
hold active during shutdown. And what matters mounting info
readonly? The final script just reads the information, so any
file written to the root system may be appropriate. As the file
needs cleaning on startup it is usually written at a location
which gets cleared on system startup (eg. /var/run).

Beside this there is another long st

ubimkvol -m and ubiformat

Paul B. Henson — 2013-05-21T18:02:58

I have an embedded use case where I need the -m option to ubimkvol and 
the ubiformat utility. As busybox doesn't currently support either, I am 
pulling in the full binaries from the mtd-utils package.

I haven't had a chance to review the code yet, but presumably if the -m 
option was as simple to implement as it would intuitively appear to be, 
somebody would have already done it :).

Before I go spend a lot of time getting familiar with busybox and 
mtd-utils code in the pursuit of adding this functionality, I wanted to 
get a little feedback if possible if anybody's already tried that and 
run into issues or determined that it's fairly complex and not worth 
doing within busybox.

Thanks much…

Re: [PATCH v2] sulogin: allow system maintenance login if root password is empty

Denys Vlasenko — 2013-05-21T15:13:59

Applied, thanks.

Re: [PATCH] make bb_ask zero its memory every time

Denys Vlasenko — 2013-05-21T14:48:17

I'd rather remove "that is zeroed every time" comment
in sulogin.c - it's smaller that way :)

Done.

Re: [PATCH] init: handle kexec clean reboot

Denys Vlasenko — 2013-05-21T14:38:17

I wasn't aware it is a common practice.
For example, who does this?
(I'm not saying you are misleading us, I'm just curious :).

Restart action runs after shutdown actions finish.
I thought usually after shutdown actions most stuff
is unmounted or remounted ro. This might complicate
parameter passing over filesystem...

Re: [PATCH v2] sulogin: allow system maintenance login if root password is empty

Tito — 2013-05-21T05:20:47

Hi,
looks good to me.

Ciao,
Tito

[PATCH v2] sulogin: allow system maintenance login if root password is empty

Jonathan Liu — 2013-05-21T01:25:55

The current password checking is unable to distinguish between the user
entering an empty password or pressing Control-D. As a result, an empty
password always results in normal startup.

We modify bb_ask to return NULL if Control-D is pressed without entering
a password. The sulogin applet is then modified to only proceed to
normal startup if bb_ask returns NULL. This covers EOF with no password,
interrupt by timeout and ^C.

Signed-off-by: Jonathan Liu <net147< at >gmail.com>
---
 libbb/bb_askpass.c   | 4 ++--
 loginutils/sulogin.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/libbb/bb_askpass.c b/libbb/bb_askpass.c
index fe2b506..e875bdd 100644
--- a/libbb/bb_askpass.c
+++ b/libbb/bb_askpass.c
< at >< at > -65,8 +65,8 < at >< at > char* FAST_FUNC bb_ask(const int fd, int timeout, const char *prompt)
 i = 0;
 while (1) {
 int r = read(fd, &ret[i], 1);
-if (r < 0) {
-/* read is interrupted by timeout or ^C */
+if ((i == 0 && r == 0) || r < 0) {
+/* EOF with no password, read is interrupted by

Re: [PATCH] sulogin: allow system maintenance login if root password is empty

Ralf Friedl — 2013-05-20T17:18:37

What about returning NULL when EOF is pressed?