Why talk about rejected work, or mistakes ? Alternatives are a good thing.
Also, as useful and widespread as Busybox is, it doesn't have to be the
be-all, end-all of embedded software; it doesn't have to package
*everything* a user might need.
As I see it, Busybox exists to provide low-resource
Hi Harald,
> 1) I like to create small self contained initramfs systems. Systems
> included in a single kernel image. So all you need to run the system is
> that single kernel image and a boot loader to start. In those initramfs
> systems i like to have only a minimum of statically linked binari
> 2) For situations where this it not possible (e.g. Busybox ash) I used
> a simple start wrapper to unblock signals.
I'm curious: how come your process 1 ash had blocked signals ?
Process 1 is launched by the kernel, and I haven't heard of a case where
the kernel blocks signals before doing so.
> If your oneit command is started with blocked signals or there action
> has been set to SIG_IGN this setting is inherited by the command you
> start. So it is better to set all signals to there default action and
> unblock before you do your exec. This way the started program has a
> clean signal
OK, so I have analyzed how a Debian Linux system boots. (Debian 6.0 with
a 2.6.32 kernel, but I don't think it has changed much with newer kernels.
The process is incredibly bloated - and I strongly suspect other mainstream
distributions are just as bad, if not worse. Those guys do a lot of work
> You tell me truth about those distro startups. Therefore I striped that
> down to nothing! On my systems the kernel start a shell script from
> mine which does necessary initializations and then the scripts
> exec's my applications main, a very minimalist program, which does
> nearly nothing unti
> In a shell script I like to check if a mounted filesystem is still in
> use by any other process in the system. If there is no more process
> using the filesystem some cleanup actions has to be done and
> afterwards the filesystem is unmounted. As the filesystem is only a
> temporary filesystem i
> Maybe you will find lsof helpful, e.g.
>
> lsof +D /my/mountpoint
lsof, as fuser, are /proc-scanning tools. Scanning /proc to then grep
the output is inefficient, and also non-atomic. I think Harald was
looking for an operation that did not involve scanning.
--
Laurent
_
> Linux 3.0.0 and 3.6.11 do not mask any signals.
Neither do Linux 2.6.32 or 3.2.34, in my experience.
>kernel (hd0,0)/vmlinuz-... root=/dev/sda2 init=/root/a.out
Depending on your kernel, it may be a little more complicated than that.
If your kernel has been compiled with an initramfs, t
> You make great arguments for stage 1 and 3, but it still seems a
> shell is ill-suited for stage 2. You would have to handle any
> signal where you didn't want the shell's default behavior, and
> if I remember right, there was also a trick needed to get the
> shell to reap zombies.
Oh, I wasn'
> The utilities are meant to be called from a shell, not from another c
> program (as a function).
I don't exactly understand what problem you're trying to point out,
but I'll use the opportunity to remind that there is *nothing* magical
with the shell. The shell, be it interactive or otherwise,
> 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
> 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
> 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.
> 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
> 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
>> 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
> "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
> 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
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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
* 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
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
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
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
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).
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-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-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-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 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.
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 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
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 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
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 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
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 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
+ 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 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
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
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 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
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 ./
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
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
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 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 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 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 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 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 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 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
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-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
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/
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 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
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
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
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
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
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 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
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 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,
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 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
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 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 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: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 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 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 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
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
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
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
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 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
1 - 100 of 326 matches
Mail list logo
