gmane.linux.busybox

[PATCH] tar: fix tar -T to add entries in the exact order as the input list

SASAKI Suguru — 2013-05-25T15:46:10

Hi,

`tar -T` in busybox v1.21.0 adds files in reverse order of the actual
inclusion list:

    $ touch 1 2 3
    $ busybox-v1.21.0 echo -e '1\n2\n3' \
        | busybox-v1.21.0 tar -T- -c \
        | busybox-v1.21.0 tar t
    3
    2
    1

This is different from GNU tar:

    $ tar --version
    tar (GNU tar) 1.26
    Copyright (C) 2011 Free Software Foundation, Inc.
    $ echo -e '1\n2\n3' \
        | tar -T- -c \
        | tar t
    1
    2
    3

I'm not sure whether this is intended or not, but attached patch will fix this:

--
SASAKI Suguru
  mailto:sss.sonik< at >gmail.com
  mailto:suguru< at >sonik.org
_______________________________________________
busybox mailing list
busybox< at >busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: ubimkvol -m and ubiformat

Paul B. Henson — 2013-05-24T22:48:55


Hmm, I didn't realize the necessary information was in the sysfs 
hierarchy, I will take a look at that. If it's not too difficult, it 
might be cleaner to just go ahead and add it to busybox so it matches 
the normal utility and so people like me that don't think about using 
shell scripts and sysfs nodes don't lose out ;). I'll post a patch for 
consideration once I have time to work on it.

Any thoughts on adding ubiformat?

Thanks…

_______________________________________________
busybox mailing list
busybox< at >busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] init: handle kexec clean reboot

Harald Becker — 2013-05-24T08:22:19

Hi Denys !


I'm not sure if you can stop process 1 this way. Process 1 accept
only signals it is actively accepting (e.g. signal handler).

--
Harald

Re: ubimkvol -m and ubiformat

Baruch Siach — 2013-05-24T07:22:27

Hi Paul,

On Tue, May 21, 2013 at 11:02:58AM -0700, Paul B. Henson wrote:

I've take a short look at the mtd-utils code, and doesn't looks so hard to 
implement in Busybox. From the code it looks like you may even be able to 
calculate the volume size in a shell script (by parsing the UBI sysfs 
entries), and then give that size to the already implemented -s option. So 
maybe adding this convenience option to Busybox is not worth it.

baruch

Re: New shell command: prlimit

Joshua Judson Rosen — 2013-05-23T15:08:47

Oh, OK. I missed the fact that prlimit already existed as a command somewhere--
it looks like that was new in util-linux 2.21 (last year; and Debian and Ubuntu
are still on util-linux 2.20).

util-linux's prlimit also appears to have a completely different argument-syntax
than ulimit; I should re-write my applet to match that syntax.


Just simplicity--since the getrlimit() call is equivalent to the prlimit() call
with pid=0, just always using prlimit meant that I only had to check once
whether the command being executed was "ulimit" or "prlimit" (so, in the shell,
"ulimit ..." effectively became equivalent to "prlimit 0 ..."). I had figured
the prlimit shell command should be able to read the limits of other processes
as well as set them (e.g.: "prlimit 1 -a" to show the the limits in effect
for the init process).

Re: [PATCH] init: handle kexec clean reboot

Denys Vlasenko — 2013-05-23T14:37:10

On Thu, May 23, 2013 at 3:02 PM, Laurent Bercot
<ska-dietlibc< at >skarnet.org> wrote:

You are right, this is ugly.

The "kill(-1, sig) and then exec PROG ARGS" tool would be better
here.

Re: [PATCH] init: handle kexec clean reboot

Denys Vlasenko — 2013-05-23T14:33:26

On Thu, May 23, 2013 at 3:02 PM, Laurent Bercot
<ska-dietlibc< at >skarnet.org> wrote:

It does.
It's just that sending any signal to pid 1 won't kill it:
all SIG_DFL'ed signals on pid 1 are ignored. Even SIGKILL.

Re: [PATCH] init: handle kexec clean reboot

Laurent Bercot — 2013-05-23T13:02:49

 Yeah, looks like it does on Linux. Mind if I still find this ugly ?



 I said "rooted in process 1", I didn't say that all the supervision
logic needed to be in process 1. If your supervision chain isn't rooted
in process 1, you can still hose your system with random SIGKILLS - as
sent by the OOM killer, for instance.
 That doesn't mean process 1 should be complex. It only needs to monitor
at least *one* other process - which is exactly what runit does.
busybox init and s6-svscan monitor several processes, they all qualify
as root of the supervision chain, too, and they're still very simple.
Don't worry, we're on the same side here.



 So we have two approaches here.

 The first one:
 * stop process 1
 * scan processes to kill everything except my own session, so my calling
shell survives.
   - this requires stopping all processes during the scan, to avoid race
conditions
   - but I want my calling shell to resume after I'm done, so I'll send
SIGCONT to everyone
   - oops, I don't want to include process 1 in my SIGCONT, else it will
restart stuff I don't want restarted
   - so I need to send SIGCONT to everyone except process 1, which
requires doing it by hand
   - after a couple hundred system calls, I can exit and return control
to my calling shell

 The second one:
 * have process 1 listen to a signal (or any kind of message) that tells
it "going to shutdown".
 * process 1 stops supervising services and executes into a shutdown
script, which can be provided by the admin.
 * said shutdown script runs as pid 1, so it can kill -9 -1 without
any further questions. One system call -> clean slate.

 Call me stubborn, but I still think the second approach is cleaner.
s6 has been designed to work like this and it has given me the fastest
shutdown/boot times of all the init systems I've tried - and I've tried
a few.

 Additionally, this approach only requires that kill(-1, something)
doesn't hit process 1, which is the case with virtually every Unix
kernel out there. Why Linux chose to do things differently makes no
sense to me: process 1 is still special with Linux since killing it
makes your kernel panic. Why choose to protect *the sending process*
from signals sent to everyone, instead of protecting *process 1*
which is the special, vital one ? This screams "half-thought design".

 Ah well. If we disagree on this, we can still agree that systemd sucks. ;)

Re: [PATCH] init: handle kexec clean reboot

Denys Vlasenko — 2013-05-23T13:29:55

On Wed, May 22, 2013 at 7:41 PM, Laurent Bercot
<ska-dietlibc< at >skarnet.org> wrote:

But shutdown from PID 1 *does that too*!

You *do* want to kill all processes, not only ones under control
of service manager, but even those you have no idea about
where they came.


Linux doesn't signal the process which does kill(-1).
They tried to "POSIX fix" it and promptly discovered that it,
tada, breaks shutdown :) I remember reading it on lkml. Fun :)

Re: [PATCH] init: handle kexec clean reboot

Denys Vlasenko — 2013-05-23T13:24:52

Which would happen with "traditional" shutdown too:
it also sends TERM+KILL to all processes.

Re: [PATCH] init: handle kexec clean reboot

Denys Vlasenko — 2013-05-23T13:22:28

On Wed, May 22, 2013 at 6:53 PM, Laurent Bercot
<ska-dietlibc< at >skarnet.org> wrote:

"kill -STOP 1" then :) Yes, it works even on PID 1. :)


Who said "it should be"? I disagree that it's best to run supervisor
as PID 1. Wait till a bug in the supervisor kills it and hangs
your box.


Yes. SIGSTOP is the signal you look for :)


Oh, I assure you, it doesn't kill itself.
I *do* use this shutdown mechanism.
It definitely works.

--
vda

Re: New shell command: prlimit

Denys Vlasenko — 2013-05-23T13:14:13

On Thu, May 23, 2013 at 4:53 AM, Joshua Judson Rosen
<jrosen< at >harvestai.com> wrote:

On, for example, Fedora, prlimit is an executable
(as opposed to shell built-in).

Therefore, it better be an applet in busybox, not built-in.

Another note:

+#if ENABLE_FEATURE_PRLIMIT
+                               prlimit(pid, l->cmd, NULL, &limit);
+#else
                                getrlimit(l->cmd, &limit);
+#endif

What's the rationale behind this change?

Re: [PATCH] init: handle kexec clean reboot

Laurent Bercot — 2013-05-23T10:44:59

 It seems to me that you guys are just reinventing s6. :)
 http://skarnet.org/software/s6/s6-svscan-1.html

 (The design explained on that page is valid with every kind of init,
but s6-svscan has been specifically tailored for this.)

Re: [PATCH] init: handle kexec clean reboot

Harald Becker — 2013-05-23T11:24:24

Hi Sam !


You are mixing keywords and program path names, the not so clean
way to define things.

You can do it that way, but you produce confusion. Clean
separation betwean keywords (and possible arguments) are the
better way and avoid conflicts.

--
Harald

Re: [PATCH] init: handle kexec clean reboot

Harald Becker — 2013-05-23T10:44:23

Hi Sam !


H is not the name of a program. It is just the information passed
to to indicate "halt".


The way it is defined is the cleanest way I know. If you want to
pass the name for a program (e.g. for kexec) you add another
keyword or letter (e.g. "X yourprogram" NL). This way there is no
conflict and you can pass whatever info you like. All this is not
defined inside Busybox binary. The script determines how the
information is used. That is you may define it as you like. Only
three values need to be predefined for the current three boot
options so the commands "halt", "reboot" and "poweroff" can
trigger the required function.

--
Harald

Re: [PATCH] init: handle kexec clean reboot

Harald Becker — 2013-05-23T08:26:00

Hi Sam !

On 23-05-2013 08:54 Sam Liddicott <sam< at >liddicott.com> wrote:

I do not fully understand your question. Neither does init depend
on any data passed nor define any structure of data.

What shall not begin with a slash?

"H", "R" and "P" where only examples for the three cases "halt",
"reboot" and "poweroff". You may pass the full words instead of
just single characters, it will use only more space. For other
cases you may chose to use any other data, like "kexec PROG ARGS".

The simple idea behind using this pipe structure is to have an
easy way to pass some information to the system shutdown script.
As the simplest way for shell scripts is to read a line of data,
the data structure is just anything ending in a newline
character. The shell script than may determine the remaining
structure by a simple case with patterns. You may pass anything
you like. Only the script matters about the structure, not the
init process.


This is the idea behind the scene. When init is shutdown on a
clean way, passing some information the final script may do
everything without need to modify binary code of Busybox. No
matter how many cases you add to this or which information is
passed.

--
Harald

AW: New shell command: prlimit

2013-05-23T06:36:39

Well, I am not general, but to me it sounds interesting.
--
Regards
________________________________________
manroland web systems GmbH -- Managing Director: Eckhard Hoerner-Marass
Registered Office: Augsburg -- Trade Register: AG Augsburg -- HRB-No. 26816 -- VAT: DE281389840

Confidentiality note:
This eMail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, you are hereby notified that any use or dissemination of this communication is strictly prohibited. If you have received this eMail in error, then please delete this eMail.

! Please consider your environmental responsibility before printing this eMail
________________________________________

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?