search

ibmibmibm / shellinabox

Automatically exported from code.google.com/p/shellinabox
Other
0 stars 0 forks source link

Cannot look up group "shellinabox" at service start #243

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. install shellinabox on Debian 7.2 from repository (apt-get install 
shellinabox) - works fine
2. after the server reboot, shellinabox was not present - not started 
automaticaly
3. when tried to run it via "service shellinabox start" the message said:
Cannot look up group "shellinabox".

What is the expected output? What do you see instead?
correct start of application

What version of the product are you using? On what operating system?
ShellInABox version 2.10 (revision 239)
Debian 7.2 - Linux XXX 3.2.0-4-686-pae #1 SMP Debian 3.2.51-1 i686 GNU/Linux

Please provide any additional information below.
how to start shellinabox automaticly with system startup?
The source privileges.c has function about it.

Original issue reported on code.google.com by hipi...@gmail.com on 26 Oct 2013 at 10:04

GoogleCodeExporter commented 9 years ago 
I got this same error right after installing shellinabox rather than on system 
reboot.  I'm not a programmer, so I don't know why this matters (maybe 
something to do with gr_len in privileges.c), but when I moved the shellinabox 
group entry to an earlier point in /etc/group (near the top with other system 
groups), shellinabox starts fine from the command-line or /etc/init.d files.

That said, I haven't tested that it comes up again at reboot (I'm not on a 
system I can reboot easily).  Perhaps someone could try this on a system where 
they can test rebooting?

Original comment by enkidush...@gmail.com on 28 Feb 2014 at 9:44

GoogleCodeExporter commented 9 years ago 
I found the reason of the error. In my case it was the OS fault (I think), as 
the group, which SHINBOX belongs to, was after another group, which contains 80 
users. So, the problem was, that OS was not able to "access" entry of any 
group, which followed the "big" users group.
I just moved the "big" entry group at the end of /etc/groups, and everything 
started correctly.

Original comment by hipi...@gmail.com on 1 Mar 2014 at 7:24

GoogleCodeExporter commented 9 years ago 
That fits my situation as well, but I wouldn't really say this is an OS issue, 
since groups with > 80 members shouldn't be a problem.  I think this points 
again to how gr_len gets set (mabye it needs a larger default?).

Original comment by enkidush...@gmail.com on 13 Mar 2014 at 4:05