headers
Natanael Copa | 1 Jul 2009 11:35
Picon
Gravatar

Re: bug or feature: env perl -w

On Tue, 2009-06-30 at 10:49 +0200, Alessandro Rubini wrote:
...

> As for glib-mkenums I get this:
> 
> tornado% head -1 /usr/bin/glib-mkenums
> #!/usr/bin/perl -w
> 
> Which is perfectly fine.

$ head -n1 /usr/bin/glib-mkenums 
#!/usr/bin/env perl -w

So its probably a bug in glib autotools script or something.
Thanks!

-nc
Permalink | Reply | 0 comments |
headers
Piyush Verma | 1 Jul 2009 11:51
Picon

Segmentation Fault

Hello Friends

When I am running busybox I get the message segmentation fault.

I am using  "armv6l-unknown-linux-uclibc-gcc" compiled by the guide line from  CLFS Embedded with uclibc.

This compiler has successfully compile linux kernel and it's running fine.

I have compiled and copied busybox executable file in rootfile system in seperate folder and when I turn it by ".busybox ls" it give sigmentation fault error message.

Any body have idea how to solve this issue ?


--
Thanks & Regards

Piyush Verma

_______________________________________________
busybox mailing list
busybox <at> busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Permalink | Reply | 502 comments |
headers
walter harms | 1 Jul 2009 12:00
Picon
Favicon

Re: Segmentation Fault


Piyush Verma schrieb:
> Hello Friends
> 
> When I am running busybox I get the message segmentation fault.
> 
> I am using  "armv6l-unknown-linux-uclibc-gcc" compiled by the guide line
> from  CLFS Embedded with uclibc.
> 
> This compiler has successfully compile linux kernel and it's running fine.
> 
> I have compiled and copied busybox executable file in rootfile system in
> seperate folder and when I turn it by ".busybox ls" it give sigmentation
> fault error message.
> 
> Any body have idea how to solve this issue ?
> 
> 

Hello Piyush,
please give us a change to reproduce the problem.
What version of Busybox you are using ?
What command you are using ? (i understand ./busybox ?)
How is your busybox compiled, What is enabled/disabled (see: .config) ?

re,
 wh
Permalink | Reply | 502 comments |
headers
Piyush Verma | 1 Jul 2009 12:16
Picon

Re: Segmentation Fault

Hi wh

I am using busybox-1.13.3.

I already  try with and without the pathc busybox-1.13.3-branch_update-1.patch

I also try with selecting minimum option only "ls & sh".

here is the configuration file as attachment.

Thanks & Regards

Piyush Verma


On Wed, Jul 1, 2009 at 6:00 PM, walter harms <wharms <at> bfs.de> wrote:


Piyush Verma schrieb:
> Hello Friends
>
> When I am running busybox I get the message segmentation fault.
>
> I am using  "armv6l-unknown-linux-uclibc-gcc" compiled by the guide line
> from  CLFS Embedded with uclibc.
>
> This compiler has successfully compile linux kernel and it's running fine.
>
> I have compiled and copied busybox executable file in rootfile system in
> seperate folder and when I turn it by ".busybox ls" it give sigmentation
> fault error message.
>
> Any body have idea how to solve this issue ?
>
>


Hello Piyush,
please give us a change to reproduce the problem.
What version of Busybox you are using ?
What command you are using ? (i understand ./busybox ?)
How is your busybox compiled, What is enabled/disabled (see: .config) ?


re,
 wh



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



--
Thanks & Regards

Piyush Verma
Product Manager.
DIGILIFE
http://www.digilifeglobal.com


Attachment (.config): application/octet-stream, 25 KiB
_______________________________________________
busybox mailing list
busybox <at> busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Permalink | Reply | 6 comments |
headers
Manuel Sahm | 1 Jul 2009 12:27
Picon

Re: Re: Re: Howto use cttyhack with login - job control turned off


>>>> Denys Vlasenko <vda.linux <at> googlemail.com> 29.06.2009 14:07 >>>
>On Mon, Jun 29, 2009 at 8:50 AM, Manuel Sahm<Manuel.Sahm <at> feig.de> wrote:
>> Hello,
>>
>> I tried your suggestion but it seems to be a problem in login :
>>
>> I add the lin ::respawn:/bin/cttyhack /bin/login in the inittab file.
>> I insert the line root:x:0:0:Super-User:/:/bin/date in the /etc/passwd
>> file.
>>
>>
>> After restart I type the correct login data an the this appears:
>>
>> 192.168.3.141 login: root
>> Password:
>> Login incorrect
>>
>> 192.168.3.141 login:
>>
>> Any ideas ?
>
>Well, it's obvious. You are entering wrong password... of course
>ogin won't start the shell!
>--
>vda
Hello, sorry the problem is still there - I tried the followig sequnce:

inittab file entry:    ::respawn:/bin/login

Login starts and I enter my Login data - the problem with job control occurs.
Then I try on the shell: /bin/cttyhack /bin/login
and after that I cannot login :
192.168.3.141 login: root
Password:
Login incorrect
192.168.3.141 login:

I enter the right password....

This problem occurs too, if the inittab file entry is ::respawn:/bincttyhack/ /bin/login

My passwd file:
root:x:0:0:Super-User:/:/bin/sh

my nssswitch.conf:
passwd:     files
group:      files
hosts:      files
networks:   files
services:   files
protocols:  files
rpc:        files
ethers:     files
netmasks:   files
netgroup:   files
bootparams: files
automount:  files
aliases:    files

I have no libnss*.so in my /lib directory

Any ideas left ?

Thanks a lot
Manuel
Permalink | Reply | 3 comments |
headers
Tito | 1 Jul 2009 12:38
Picon
Favicon

Re: Howto use cttyhack with login - job control turned off

On Wednesday 01 July 2009 12:27:05 Manuel Sahm wrote:
> 
> >>>> Denys Vlasenko <vda.linux <at> googlemail.com> 29.06.2009 14:07 >>>
> >On Mon, Jun 29, 2009 at 8:50 AM, Manuel Sahm<Manuel.Sahm <at> feig.de> wrote:
> >> Hello,
> >>
> >> I tried your suggestion but it seems to be a problem in login :
> >>
> >> I add the lin ::respawn:/bin/cttyhack /bin/login in the inittab file.
> >> I insert the line root:x:0:0:Super-User:/:/bin/date in the /etc/passwd
> >> file.
> >>
> >>
> >> After restart I type the correct login data an the this appears:
> >>
> >> 192.168.3.141 login: root
> >> Password:
> >> Login incorrect
> >>
> >> 192.168.3.141 login:
> >>
> >> Any ideas ?
> >
> >Well, it's obvious. You are entering wrong password... of course
> >ogin won't start the shell!
> >--
> >vda
> Hello, sorry the problem is still there - I tried the followig sequnce:
>  
> inittab file entry:    ::respawn:/bin/login
>  
> Login starts and I enter my Login data - the problem with job control occurs.
> Then I try on the shell: /bin/cttyhack /bin/login
> and after that I cannot login :
> 192.168.3.141 login: root
> Password:
> Login incorrect
> 192.168.3.141 login:
>  
> I enter the right password....
>  
> This problem occurs too, if the inittab file entry is ::respawn:/bincttyhack/ /bin/login
>  
> My passwd file:
> root:x:0:0:Super-User:/:/bin/sh
>  
> my nssswitch.conf:
> passwd:     files
> group:      files
> hosts:      files
> networks:   files
> services:   files
> protocols:  files
> rpc:        files
> ethers:     files
> netmasks:   files
> netgroup:   files
> bootparams: files
> automount:  files
> aliases:    files
>  
> I have no libnss*.so in my /lib directory
>  
> Any ideas left ?
Hi,

Why do you not try to add at least libnss_files.so?
What libc are you using?

Ciao,
Tito
> Thanks a lot
> Manuel
>  
> 
>
Permalink | Reply | 0 comments |
headers
Kjetil Oftedal | 1 Jul 2009 13:44
Picon

HTTPD-CGI Connection lost

Hi,

I am working on a CGI-program that is going to be run using the busybox httpd.
As far as I can see from the httpd-source the following scenario isn't handled:
The webapplication uses comet/the client connection hangs open until an event
happens in the CGI-program. If the client connection is closed remotely while
the CGI-program is blocking/waiting/working the CGI-program is never notified
of this by the httpd, not even killed, and may run indefinitly.

Can someone confirm that this is correct?

---
Kjetil Oftedal 

_______________________________________________
busybox mailing list
busybox <at> busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Permalink | Reply | 1 comment |
headers
Cathey, Jim | 1 Jul 2009 18:48

RE: Re: Re: Howto use cttyhack with login - job control turned off

>I enter the right password....

How can you be sure?  How can we be sure?  :-) Try deleting
the root password (in the /etc/shadow file) to see if it'll
let you in then.  (The 'x' in the passwd file implies you're
using a shadow password file.)

-- Jim
Permalink | Reply | 0 comments |
headers
Denys Vlasenko | 2 Jul 2009 01:11

Re: Howto use cttyhack with login - job control turned off

On Wednesday 01 July 2009 12:27, Manuel Sahm wrote:
> >> After restart I type the correct login data an the this appears:
> >>
> >> 192.168.3.141 login: root
> >> Password:
> >> Login incorrect
> >>
> >> 192.168.3.141 login:
> >>
> >> Any ideas ?
> >
> >Well, it's obvious. You are entering wrong password... of course
> >ogin won't start the shell!
>
> Hello, sorry the problem is still there - I tried the followig sequnce:
>  
> inittab file entry:    ::respawn:/bin/login
>  
> Login starts and I enter my Login data - the problem with job control occurs.
> Then I try on the shell: /bin/cttyhack /bin/login
> and after that I cannot login :
> 192.168.3.141 login: root
> Password:
> Login incorrect
> 192.168.3.141 login:
>  
> I enter the right password....
>  
> This problem occurs too, if the inittab file entry is ::respawn:/bincttyhack/ /bin/login

Please got to login.c, find this fragment:

                pw = getpwnam(username);
                if (!pw) {
                        strcpy(username, "UNKNOWN");
                        goto fake_it;
                }

                if (pw->pw_passwd[0] == '!' || pw->pw_passwd[0] == '*')
                        goto auth_failed;

                if (opt & LOGIN_OPT_f)
                        break; /* -f USER: success without asking passwd */

                if (pw->pw_uid == 0 && !check_securetty())
                        goto auth_failed;

                /* Don't check the password if password entry is empty (!) */
                if (!pw->pw_passwd[0])
                        break;
 fake_it:
                /* authorization takes place here */
                if (correct_password(pw))
                        break;

and change it into:

                pw = getpwnam(username);
                if (!pw) {
                        strcpy(username, "UNKNOWN");
bb_error_msg("BAD USERNAME");
                        goto fake_it;
                }

                if (pw->pw_passwd[0] == '!' || pw->pw_passwd[0] == '*')
{bb_error_msg("BAD pw_passwd");
                        goto auth_failed;
}

                if (opt & LOGIN_OPT_f)
                        break; /* -f USER: success without asking passwd */

                if (pw->pw_uid == 0 && !check_securetty())
{bb_error_msg("BAD pw_uid or !securetty");
                        goto auth_failed;
}

                /* Don't check the password if password entry is empty (!) */
                if (!pw->pw_passwd[0])
                        break;
 fake_it:
                /* authorization takes place here */
                if (correct_password(pw))
{bb_error_msg("correct_password FAILED");
                        break;
}

What do you see now?
--
vda
Permalink | Reply | 0 comments |
headers
Denys Vlasenko | 2 Jul 2009 12:31

Re: HTTPD-CGI Connection lost

On Wed, Jul 1, 2009 at 1:44 PM, Kjetil Oftedal<oftedal <at> gmail.com> wrote:
> I am working on a CGI-program that is going to be run using the busybox
> httpd.
> As far as I can see from the httpd-source the following scenario isn't
> handled:
> The webapplication uses comet/the client connection hangs open until an
> event
> happens in the CGI-program. If the client connection is closed remotely
> while
> the CGI-program is blocking/waiting/working the CGI-program is never
> notified
> of this by the httpd, not even killed, and may run indefinitly.

Yes. I don't know what the valid behavior would be. Should we:
(a) close CGI input fd (httpd->CGI) on the httpd's end?
 and/or
(b) close CGI output fd (CGI->httpd) on the httpd's end?
 or
(c) send a signal to CGI (which one)?
 or
(d) do nothing?

IIRC, currently:

If we detect an error _writing_ to network,
httpd exits, and thus CGI will see write errors next time
it tries to write something.

If we detect _read_ error from a network (which we do only
if there is a POSTDATA to read), then we just stop trying
to read from network. httpd does not exit, but closes
the httpd->CGI fd. CGI can detect it if it tries to read
from it.

> Can someone confirm that this is correct?

It might be. Someone needs to google for standard practice on this.
What does apache do?
--
vda
Permalink | Reply | 0 comments |

Gmane