On 18/03/2015 18:08, Didier Kryn wrote:
No, you must write to the pipe to detect it is broken. And you won't
try to write before you've got an event from the netlink. This event
will be lost.
I skim over that discussion (because I don't agree with the design) so
I can't make any substantial co
On 15/03/2015 23:44, Harald Becker wrote:
There are to many stupid programmers out there, who would try to add
something like that into system management related programs. Couldn't
go worser. Even if it works, at the first glance, it is error prone,
and the next who change message size of one pro
On 15/03/2015 22:47, James Bowlin wrote:
kernel guaranties not only atomicity for write operations, but
also for read operations (not in POSIX, AFAIK).
The post you were replying to already admitted that multiple fifo
readers was not POSIX complia
On 15/03/2015 21:54, Harald Becker wrote:
My lead in was: "just for curiosity", and that's it, it works on many systems.
... but I never proposed, doing something like that. It's what my lead in says:
curiosity.
Okay, fair enough. Please let's not do it then. :)
--
Laurent
On 15/03/2015 20:41, James Bowlin wrote:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html :
^
For goodness sake. This appears to be an argument merely for the
sake of having an argument.
This is POSIX.1-2008, the very specification that Linu
On 15/03/2015 19:39, Harald Becker wrote:
On most systems it is perfectly possible to have multiple readers on
a pipe, when all readers and writers be so polite to use the same
message size (<= PIPE_BUF). On most (but not all Unix systems) the
kernel guaranties not only atomicity for write opera
On 15/03/2015 15:52, Natanael Copa wrote:
I have simplified the long-time living netlink listener more by
forwarding the netlink socket and letting the handler read
directly from netlink. This factorize out the pipe and remove the need
of any micro protocol.
As I wrote in another message, ther
On 15/03/2015 14:29, Natanael Copa wrote:
It should be possible to solve the hotplug problem by setting up
netlink listener, wait for event, when event arrives fork helper and
just hand over the netlink socket filedescriptor to the child. That way
we avoid pipes/fifos alltogehter. And we avoid th
On 14/03/2015 20:23, Rich Felker wrote:
Could you elaborate on how you measure that? With musl only the parts
of stdio you actually use will be linked, and use of exit does not
result in linking of any additional code, since the startup code has
to call exit(main(...)) anyway. In any case exit an
On 14/03/2015 01:20, Harald Becker wrote:
I'm using none blocking I/O and expect handling of failure
situations, e.g writing into pipe fails with EAGAIN: poll wait until
write possible with timeout. then redo write
Hm, after checking, you're right: the guarantee of atomicity
applies with nonbl
On 11/03/2015 08:45, Natanael Copa wrote:
The netlink listener daemon will need to deal with the event handler (or
parser as you call it) dying. I mean, the handler (the parser) could
get some error, out of memory, someone broke mdev.conf or anything that
causes mdev to exit. If the child (the ha
On 13/03/2015 21:32, Michael Conrad wrote:
I stand corrected. I thought there would be a partial write if the
pipe was mostly full, but indeed, it blocks.
Except you have to make the writes blocking, which severely limits
what the writers can do - no asynchronous event loop. For a simple
"cat
I think that adding hotplug helper management in a hotplug helper
needlessly complicates things.
It's easy enough to run the following in the init sequence:
1. start a netlink listener with a long-lived handler
2. coldplug stuff
3. register a hotplug helper
4. kill the netlink listener.
On 12/03/2015 20:07, Harald Becker wrote:
Don't you risk resource problems for hotplug handler processes, when
the system is under such pressure?
No and that's my point. If you don't have swap, it's likely that
your box is embedded and you won't spend your life plugging and
unplugging USB stic
ACK ... but what do you think about e.g. tcpsvd (accepting incoming
tcp connections), or netlink reader?
tcpsvd is precisely a super-server. That's where I would draw the line.
A netlink reader probably has its place.
But really, I have my own super-servers and my own netlink reader, so
I h
http://git.alpinelinux.org/cgit/ncopa/nldev/tree/nldev-handler.c
- child(): the parent is blocking as long as the child is running -
this is not safe if a user registers a bad-behaved helper. The
parent should be able to kill the child after a timeout.
- line 76: especially since you're block
On 12/03/2015 18:26, Isaac Dunham wrote:
[1] The format proposed by Laurent uses \0 as an "line" terminator;
I think it might be better to use something that's more readily
generated by standard scripting tools from uevent files, which would
make it possible to use cat or env to feed the mdev par
On 12/03/2015 16:19, Natanael Copa wrote:
netlink listener code that needs to be in memory all the time:
http://git.alpinelinux.org/cgit/ncopa/nldev/tree/nldev.c
A few comments:
- disableoom(): it's a generic operation for any daemon you don't
want to have killed, so you can factorize it: yo
On 12/03/2015 13:10, Denys Vlasenko wrote:
I find it suboptimal to have, say, a hotplug daemon lingering
in the system five hours after the last hotplug event happened.
On most systems, it will be swapped away in that case. (Whereas
if the logic is in the kernel, that memory cannot be swapped.
On 11/03/2015 19:02, Harald Becker wrote:
It is neither a knowledge nor any technical problem, it is preference:
I want to have *one* statical binary in the minimal system, and being
able to run a full system setup with this (system) binary (or call it
tool set). All I need then is the binary, so
On 11/03/2015 15:56, Harald Becker wrote:
And one point to state clearly: I do not want to go the way to fork a
project (that is the worst expected), but I'm at a point, I like /
need to have Busybox to allow for some additional or modified
solutions to fit my preferences
I don't understand th
On 11/03/2015 19:14, Isaac Dunham wrote:
And second, I'm not really understanding what's constant when I write
"const char *".
I had thought that it meant that the pointer was immutable, and that
"char *const STRING" marked the contents of "STRING" as immutable. Is
that backwards?
Yes.
Not
On 11/03/2015 17:10, Harald Becker wrote:
And what is wrong with a long lived daemon?
Ok, what I see is brain damaged developers writing big monolithic
long lived daemons, which suck up tons of memory and / or cpu power
:( ...
... this is not what I understand of a carefully designed long lived
On 11/03/2015 14:02, Denys Vlasenko wrote:
But that nldev process will exist for all time, right? That's not elegant.
Ideally, this respawning logic should be in the kernel.
Well there is already a kernel-based solution: hotplug.
Sure, it's not serialized, but it's there. If you want somethin
Hi Harald,
I'm sorry if I came across as dismissive or strongly opposed to the idea.
It was not my intent. My intent, as always, is to try and make sure that
potential new code 1. is worth writing at all, and 2. is designed the
right way. I don't object to discourage you, I object to generate
On 09/03/2015 09:41, Natanael Copa wrote:
What I'd like to do is:
change mdev to:
- be able to read events from stdin. same format as from netlink socket.
The thing is, the format from the netlink socket is a bit painful to parse;
the hard part of netlink listeners isn't to actually listen
Hi Harald !
1) Starting up a system with mdev usually involves the same steps to
mount proc, sys and a tmpfs on dev, then adding some subdirectories
to /dev, setting owner, group and permissions, symlinking some
entries and possibly mounting more virtual file systems. This work
need to be don
On 02/03/2015 05:40, Neale Pickett wrote:
I'm running runsvdir as PID 1
Hi Neale,
runsvdir is actually not intended to be run as process 1.
runit's model is to have the "runit" program itself run as process 1,
and it spawns a program for every stage: /etc/runit/{1, 2, 3}.
Traditionally, peopl
On 17/02/2015 22:37, Rich Felker wrote:
Read the new code again. It works fine for that case as far as I can
tell.
Indeed, my apologies (and I realized that after Denys' message).
I always get confused by printf conversion specifications as soon
as there's anything more than a single conversi
On 17/02/2015 13:52, Explorer wrote:
My original motivation was to avoid that annoying comment saying that
"it's buggy after year ", and I believe it should be written right
in the first place.
Would you prefer the following comment: "It's buggy after year 9" ?
(Not saying that the p
Why? If Denis does not have time for the project, then we cannot
really blame him. On the other hand, if a fork could work better with
someone standing up, why not?
Forking a project divides resources and weakens both children. It is
a possibility for big projects with lots of resources and sev
Le 20/10/2014 13:36, Bartosz Golaszewski a écrit :
Busybox already uses sendfile in httpd. This patch proposes to use it
globally to copy data between file descriptors.
I haven't been keeping up-to-date with sendfile() in the last couple of
years, but AFAICR sendfile() was limited in the type
Le 19/10/2014 15:22, walter harms a écrit :
I would vote for a busybox-next (or what you call it).
A branch that easly fold back into the main but contains all
the recent patches.
That may be desirable indeed.
However, *forking* the project would be a terrible idea.
--
Laurent
On 01/09/2014 09:20, dietmar.schind...@manroland-web.com wrote:
That does not follow.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html#tag_17_04
talks in the OPTIONS section about "arbitrary options that the implementation may
provide as an extension"
(as --help is) an
The question is would it break something if --help would return EXIT_FAILURE
everytime ?
Well the usual GNU --help behaviour is to return EXIT_SUCCESS after
displaying the help.
false is the exception, not the rule, and should be specialcased in busybox
as it is in GNU coreutils.
My opinion
On 30/08/2014 10:33, walter harms wrote:
Does POSIX specify anyhing about that "--help" ?
POSIX does not specify anything about --help. It's a GNU extension,
like every long option.
For true or false, POSIX does not specify any option at all:
http://pubs.opengroup.org/onlinepubs/9699919799/
On 2014-08-11 03:27, James Bowlin wrote:
If someone had done a frugal install (copy the squashfs file to
internal hd) or if they enable static root persistence (which
opens a persistence file on the internal hd ) then it is
impossible to cleanly umount the hd without doing a pivot_root
first. Th
I don't quite understand what you are suggesting.
Ah, I'm sorry, I hadn't realized you were not the OP, and I have
replied as if you were trying to bring up a system - but you are
just trying to shut it down.
Well a shutdown isn't really something I've mastered. I've always
considered it was
On 2014-08-10 20:49, Michael Conrad wrote:
Gentoo-uclibc in a chroot is my weapon of choice these days. I hate
cross-compiling with a passion.
(would love to see someone put together a gentoo-musl! )
I can't wait for Rob to finish the Aboriginal Linux move
to musl. The Aboriginal toolchains
On 2014-08-10 11:29, James Bowlin wrote:
I've been able to deal with processes that spawn children on
shutdown but it might be possible for someone to intentionally
build a fork bomb that I would have trouble with. I believe that
if someone with root is malicious enough then they can defeat any
On 2014-08-10 08:07, James Bowlin wrote:
BTW: I use the start-time of processes to find all the processes
that need to be killed. Using pid is unreliable because it can
wrap on 32-bit systems.
The *only* way to be 100% sure they are no remaining processes at
some point in a system's lifetime
On 07/16/2014 02:40 PM, ram kumar wrote:
I have requested for option 43 by sending my vendor class, the dhcp
server is correctly sending the vendor specific IP address that I have
given in config file , Im able to see this through wireshark...now how
do I access the IP from udhcpc?? where does ud
On 02/07/2014 19:54, Joshua Judson Rosen wrote:
But, looking at the calendar today..., it looks like it's been almost
a decade since he at least relented on the "license-free software" thing
and dedicated everything to the public domain; so maybe enough time
has passed for the controversy surroun
On 02/07/2014 19:24, Joshua Judson Rosen wrote:
I don't really have any postprocessing I want to do, I just want
to rotate my logfiles with different limits e.g.: 100 generations of
the log that records only messages at LOG_NOTICE and higher
vs. 10 generations of the log that records LOG_DEBUG an
On 02/07/2014 16:02, Joshua Judson Rosen wrote:
And even if syslogd has some warts, it has the major benefit of being
what's used by huge swaths of open-source software that I can mostly
just use as-is if my logging system is syslog-compatible.
Of course it is necessary for a system to impleme
On 07/02/2014 02:36 PM, Denys Vlasenko wrote:
How about using svlogd?
That would be a better idea indeed.
The complete case against syslog can be read here:
http://skarnet.org/software/s6/s6-log.html#diesyslogdiedie
--
Laurent
___
busybox mailin
On 27/06/2014 14:26, Rich Felker wrote:
The lack of an iptables command in Busybox is something that would be
nice to fix, especially since the official iptables is bloated and
(last I checked) requires dynamic linking.
I haven't checked for a year or so, but when I last tried it, I could
get
Well, unlink takes '--version' and '--help' as options. I think
there's a conflict between open standard and coreutils' oddity to
bring command syntax and version information with command line
switches.
unlink is not the only nonconforming executable in GNU coreutils.
true and false, for instan
From the (perfectly working) busybox system:
/export PATH=/bin:/sbin:/usr/bin:/usr/sbin
mount -t sysfs sysfs /sys
mkdir -p /dev/pts
mount -t devpts devpts /dev/pts
mount /dev/mmcblk0p5 /mnt/root/
Then I tried 2 ways:
*1) pivot_root*
/cd /mnt/root
pivot_root . ./initrd
./bin/mount -n --move ./
On 05/30/2014 10:16 AM, Bartosz Gołaszewski wrote:
I've checked the times just by looking up all the applets in a loop
and measuring the time using gettimeofday() - the results are: ~220
microseconds for bsearch and ~150 microseconds for hashtable on my
linux laptop. Is it significant? I think s
Does this provided a noticeable performance increase? Do you have
benchmarks?
+1. I'm not convinced this is useful. Maybe for looping sh scripts that
prefer applets (i.e. do not perform an execve() everytime busybox is
called), but I'm willing to bet that even in that kind of script the
perform
On 23/05/2014 18:59, Joshua Judson Rosen wrote:
Especially if anyone else has been in the same sort of situation
(really needing to keep as much persistent log-data as will possibly
fit into their available storage) and especially if you've found
other ways of dealing with it.
You should never
On my system I modified networking/ifupdown.c to call "kill -9" instead of
"kill" to kill udhcpc (lines 539 and 617) and now udhcpc stops as expected when I bring
the related interface down. However, I've been through networking/udhcp/dhcpc.c and I don't see
any obvious reason why it won't r
+ IF_FEATURE_LOGROTATE_CMD(
+ if (G.logrotateCmd) {
+ system(G.logrotateCmd);
It would be a good idea to test the return code of the external
command and schedule a later rotation if it is nonzero.
+ } else) if (G.logFileRotate)
On 02/05/2014 13:30, Morten Kvistgaard wrote:
When I build “daemon” applets into Busybox, I’m wondering about the ram usage.
(...)
But when executing it, the ram usage seems to be [Busybox flash size + local
ram allocations].
Meaning that instead of 50k ram, it takes up 350k. Or so my top comma
Yes, there's still much to learn. Do you happen to know of some
popular examples?
A lot of long-running processes that spawn several children and assign
different tasks to them will do this, for informative purposes.
(I personally think that the argv of a process is not the right place
for a
On 21/03/2014 23:10, Cathey, Jim wrote:
The only thing BB would need would be to isolate initialization
into separate functions that would be grouped together by the
linker. (And an associated link control file.) The usual demand-paged
kernel will take care of the rest.
Yes, that would defi
Are you seriously suggesting to add dlopen()ed libraries to busybox
to offset the bloat of adding a config file parser to ntpd ?
This is the exact kind of "design" that busybox is fighting.
Please readhttp://busybox.net/FAQ.html#goals and
http://busybox.net/FAQ.html#tips_memory , as well as
On 18/03/2014 21:28, Laszlo Papp wrote:
Exactly the opposite. You really missed the point of this thread. The
whole point about configuration file is to unify it, for me at least.
But what makes you think a configuration file would unify the way
distributions run busybox ntpd more than the cu
On 18/03/2014 20:29, Mike Dean wrote:
So the deficiency of your software can always be blamed on your software's
userbase? Sounds like a winning philosophy.
The fact that you still think using command-line arguments instead of
a config file is a "deficiency" shows that you are missing the po
On 18/03/2014 20:12, Mike Dean wrote:
So it's difficult to provide and document a configuration file like this?
It's not difficult.
But it conflicts with some of the goals of Busybox.
Parsing a config file has several drawbacks:
- It is much more complicated than reading command-line argum
Just chiming in to support Harald.
Busybox provides a usable ntpd interface. Calling ntpd with the
suitable arguments is the job of the init scripts, not Busybox;
if people have trouble starting ntpd, it's the responsibility of
their distribution packagers, not of Busybox; if they are the
dist
On 16/03/2014 03:06, Rich Felker wrote:
/tmp is not suitable for this; you can never assume the ability to
create a fixed-name file in /tmp, since the namespace of /tmp is
shared on a first-come, first-served basis. Any programs using /tmp
except for creating randomly-named files there are buggy.
On 2014-03-13 22:16, John Spencer wrote:
You could make it rigorous by touching a fixed filename in /var/run
each time and sleeping until a fixed interval has elapsed past that
file's mtime. Unless you do that though, adding a delay is just a
nuisance. It does not hinder competent attackers and i
On 2014-03-05 17:40, Yan Seiner wrote:
I am trying to run a script every second. I set up two scripts:
Very dumb question: if your script execution time is much smaller
than one second, why not simply "while true ; do update ; sleep 1 ; done" ?
(Or better, "update ; exec sleep 1" in a runit/s
On 2014-01-24 06:16, Denys Vlasenko wrote:
Admit it - "traditional" SysV init is neanderthal.
Not merely "simple" (that's not a bad thing!) - but
awkward too.
Oh, I totally agree - I wrote s6, remember ? And I'm so much
more interested in getting the design and the code right than
in seeing it
On 2014-01-23 19:28, Bernhard Reutner-Fischer wrote:
Fix systemd then.
systemd is broken by design. The only way to fix it is to scrap it
and design another, non-broken init system from the ground up. And
it has already been done, several times. (By me, among others.)
But apart from that I'
On 2014-01-10 19:27, Rich Felker wrote:
Note that this kind of approach STILL does not protect you from
vulnerabilities in the dynamic linker (avoiding them would require
making both the wrapper and busybox binary static-linked)
Which is the case for me.
or libc startup code (inevitable).
Did you see the patch John Spencer sent me to make it actually work?
About three dozen more lines of code.
John Spencer's patch focuses on making ping work without root privileges.
My code focuses on giving root privileges to applets that need it (such
as current ping) without making the who
You're performing too much work copying your argument list. :P
The wrapper should be entirely transparent: busybox shouldn't
even notice it has been run through it, so it should be called
with the exact same argv. Here's what I do.
Notes:
* untested, please check carefully. The actual code
They were order of magnitude more problematic
when multi-user machines were the norm.
True enough, but it is still the case, for a good definition of "user".
Most machines today only have one human user, but there are a lot
of uids and gids used to run daemons with separate privileges. It is
* make a single busybox binary with all the applets I need. My
busybox binary is NEVER setuid.
* compile a separate small C program that tests whether
`basename $0` is in a list of accepted words, and if it is the
case, execs into "/bin/busybox `basename $0` $@". Make that separate
binary
An attacker who only manages to subvert your user account,
of course, can't get at the precious things like /usr/bin/* files
and modify or delete them.
He can only read your locally saved emails,
browser's cache and saved passwords
of your bank website login.
Oh, wait...
Eh, I didn't preten
making ping suid in the context of busybox basically means "make the
entire busybox binary suid" and that is definitely a bad idea (an
example that comes to mind is the wall vulnerability discovered
recently).
Hi,
Busybox drops suid privileges for applets that don't require it
even before the a
Hi Didier,
I actually have a jffs2 filesystem on another part of the flash
memory, but I decided not to use it for the purpose, for one reason: A
single stupid bug might make the device non-bootable. Because, even if
the jffs2 or squashfs is initially mounted read-only, the main reason to
Hi Harald,
... still have the question: How is a read only file system, like
squashfs easier to maintain than a initramfs? IMO you only
compare with kernel bundled initramfs usage, but initramfs means
cpio archiv which may be loaded separately.
Well, my point was comparing with a kernel-bu
And here the question: How is it simpler to maintain? squashfs is
a read only file system, so you can't change things directly.
Same as in initramfs: You need a copy of the root file system
tree to put in your changes, then you need to create your new
root file system (squashfs on one hand, cpio
But about the usefullness of initramfs, I think you are wrong.
I don't think I could do the job without it.
Hi Didier,
Eh, you could. You have some flash to boot the kernel from: you could
as well have a small squashfs root filesystem on it with a script that
performs all the initializatio
You are making a very *big* assumption that the kernel can find
the real root filesystem without userspace help. In cases where
the kernel can't - initramfs/initmpfs is in fact very useful.
Show me a precise, real-life example, and I'll tell you how I would
proceed. Or agree with you.
Act
On 2013-12-16 01:08, Rob Landley wrote:
The most recent kernel has my initmpfs patches, meaning initramfs
can now be a tmpfs instead of ramfs.
[snip blurb]
You're listing reasons why initramfs (or initmpfs, if you prefer) is
more logical than it was before, more convenient, etc. All this may
Hi Harald,
I think Piotr's binaries are static; he's complaining about their size,
compared to the size of the binaries that can be found on busybox.net.
My guess is that Piotr tried a static compilation with the glibc, which
will indeed pull in 2 MB of random crap. Whereas the prebuilt binar
I don't know if I understand it right.
Does it mean that as long as we don't do some strange redirections of standard
IO in our initramfs, we don't need to add this option when switching root? So
in most cases we don't need to reopen the stdio, right?
Unless your real root's /dev/console is
I'm new to busybox, and I'm stuck on the shell builtin cmd
"ulimit" which is used for configuring codedump on our embedded board.
As you said, "ulimit" is a shell builtin, meaning it's a reserved
word interpreted by the shell, not a busybox applet. It will not appear
in the list of busy
ent /usr updates. It is suboptimal for an
embedded
or otherwise specialized system.
--
Laurent Bercot
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Yeah. That's why I'm somewhat confused, as busybox is installing more programs
into /bin and /sbin directories than what are specified in FHS.
Take /bin as an example, the FHS only specifies a few commands to be there.
http://www.pathname.com/fhs/pub/fhs-2.3.html#BINESSENTIALUSERCOMMANDBINARIE
but even using "$@" whitespace in a URL must be correctly
escaped or it will not work with busybox wget and with real wget.
The reason for this is the point when arguments get expanded or
split into words.
At this point, a shameless plug feels appropriate.
The execline language was precise
you will see the values of your variables doesn't change when
commands run in a subshell ... and piping informations always
means passing data between separate processes, so it forces the
command to be run in its own subshell.
You have to admit that it is not intuitive or user-friendly, to
sa
How do you know for sure ?
As Pere said, because this is BusyBox uname.
That would only prove that the "uname" implementation is Busybox's. That
wouldn't say anything about the rest of the system.
Running BusyBox uname on a non-BusyBox system (that is, configuring
BusyBox to build only th
But I'd call such a system "BusyBox/Linux" instead, since BusyBox is the
userspace, regardless of the C library in my opinion.
How do you know for sure ?
Busybox isn't the only alternative userspace. There are other several,
if lesser-known, projects that provide low-level userspace tools.
t
I take it from your bug report that having pfd[0].events zeroed
doesn't prevent POLLHUP|POLLERR from being reported :(
Hi Denys,
POSIX says:
If the value of fd is less than 0, events shall be ignored, andrevents shall be
set to 0 in that entry on return from poll().
In each pollfd structure
> Autotools-based can be good or bad for cross-compiling. The biggest
> issue is that lots of people write broken tests that need to run test
> programs to get the results they want.
As long as there are differences between systems, build-time tests
will be necessary to check for what the system
On Fri, May 31, 2013 at 02:46:51PM -0400, Mike Frysinger wrote:
> not to go way off topic for this list
Ah, if you start advocating one way, it's only fair that people
advocate the other way. :)
> autotools tends to work a lot more reliably than
> $random-build-system-of-the-day.
That's a tes
> Isn't that because killall kills by name? It would have to scan the
> process list, then.
We're talking about killall5, which does not kill by name. ;)
--
Laurent
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listi
> "kill -STOP 1" then :) Yes, it works even on PID 1. :)
Yeah, looks like it does on Linux. Mind if I still find this ugly ?
>> necessary to disable supervision. If the supervision chain is rooted in
>> process 1 as it should be,
>
> Who said "it should be"? I disagree that it's best to run su
>> I really like the idea that init can be made to exec itself with
>> something else! It could be another linuxrc that execs another
>> init!
>
> 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 t
> 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?
It is still necessary to have some mini
> 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.
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
> 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.
> 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.
Erratum: kil
> 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 are forgetting two things ;)
1. Supervision systems rooted in process 1 - i
101 - 200 of 330 matches
Mail list logo