Quote:
Originally Posted by twobob
In other news I was CERTAIN the alias list just COULD NOT be this big... something should die horribly... or maybe the ram of the machine would be sucked into oblivion.
The machine hasn't been turned off for weeks so I'm going to bite the bullet and do a full restart (to give me a no-leak base memory reading) and see if something dies.
Wish me luck.
EDIT: Okay went through fine...
about a 90Mb footprint these days at boot? Is that right? anyone?
One suprise is highlighted in the picture.
Err. why is the new busybox, starting telnetd.
in fact. why is the new busybox doing anything at reboot?
|
Nice test - -
That the existing scripting would run under the new busybox.
Well, somebody had to try the re-boot function, some time.
Nice to know all of this work didn't turn in into a re-brick function.
- - - -
To answer the little mystery question would really require to break out the initramfs scripting for examination, but ....
Somewhere in there, the "old" shell picked up the alias list.
And / Or picked up the changes to the PATH environment variable.
I would go with "AND" - since both are required to make the shell that is running (old or new) recognize a scripted command as an alias and be able to find the "new" busybox on the PATH.
An initramfs script transfers control to the system that was setup with some version of:
exec /bin/sh </dev/console >/dev/console ... ... ...
or
exec /init </dev/console >/dev/console ... ... ...
With either a "switch_root" or a "pivot_root" command tossed in for flavor (which includes the basics of an "exec" call).
I.E: The command shell running when the regular userspace is first hit from early userspace is "a chained continuation" not a "child continuation".
(See the later quoted explanation of a "child" or "sub-shell" process.)
So, the question gets promoted to:
How did the "chained continuation" pick up the . .alias and the PATH= changes?
Answer: From the fixed name initialization files that you mentioned earlier you had to add and/or alter.
(The ones you noted a "stock" K3 does not have.)
New question: Is this a bad thing?
Duh...
I don't know. I do know it is what we wanted to happen, sometime later after months of testing.
Guess you left some skid marks on that part of the learning curve and maybe bump'd across the in-field a bit.
Why did telnetd get started?
Blame that one on lab126 slop.
An embedded system under development very often has telnetd running in the image as a development aid.
When ready for release - that telnetd may (often is) disabled.
How?
By removing the init rc.?? script to start it.
By removing the iptables port 21 "hole".
By removing telnetd from the system image.
We know that lab126 did #2 above - we can read the iptables rules.
Listing the old busybox features should tell us if they did #3 above.
What they evidently did not do was #1 above.
And when you provided (unintentionally) access to the new busybox with telnetd included, it started working again.
Duh...
Add a new input chain rule that does a -j accept for port 21 - then reload the iptable rules.
Whoot! You should be able to telnet into the box from **any** network connection (unless you qualify the source in the rule).
So much for the "I can't ssh into my K3" problem reports.
Who needs it? (ssh, dropbear, etc, etc).
Parts above are pure speculation - but it makes a story that hangs together.