/etc/init.d/dropbear restart doesn't work

[alih]

"/etc/init.d/dropbear restart" doesn't kill dropbear. That's because dropbear is only a symlink.

Fix (I'll try to attach a patch): in /etc/init.d/dropbear replace DAEMON=/usr/sbin/dropbear with DAEMON=/usr/sbin/dropbearmulti.

Running 2008.9.20 snapshot of Om 2008.

[alih]

no, my patch doesn't work - it can't start it then. "dropbearmulti" should be used only when stopping.

[zecke]

Plese see ​http://wiki.openmoko.org/wiki/Bug_Filing_Policy. Specially when you have a patch please add HasPatch? to the keywords otherwise we will not see your patch. Trac does not send mails when something is attached, and there is no way to query for attachments.

[zecke]

Assigning it to the distro.

[Treviño]

Replying to zecke:

Plese see ​http://wiki.openmoko.org/wiki/Bug_Filing_Policy. Specially when you have a patch please add HasPatch? to the keywords otherwise we will not see your patch. Trac does not send mails when something is attached, and there is no way to query for attachments.

Sorry if I'm completely OT with the bug reporting, but I'm replying to the HasPatch? thing: how can we set these tags when putting in a patch after that a bug has already been reported? I don't see any editable field here to modify the tags!
I figure it should be added; we, users, have too few permissions in trac!

[zecke]

Replying to Treviño:

Sorry if I'm completely OT with the bug reporting, but I'm replying to the HasPatch? thing: how can we set these tags when putting in a patch after that a bug has already been reported? I don't see any editable field here to modify the tags!
I figure it should be added; we, users, have too few permissions in trac!

Hehe. For many being able to set a component is... We have different groups and there is no reason to not give externals the same rights as internals. Talking about HasPatch? and keywords you should be able to add it. In regard to your question there will be a custom boolean field HasPatch? soon(tm) you could check if there is a ticket at the admin trac and if not file one. :)

[julian_chu]

I cannot reproduce this ticket.
The Restart is just calling stop+start.
Both of them works for me.

$ps ax |grep dropbear |grep -v grep

2242 ? Ss 0:00 /usr/sbin/dropbear -r /etc/dropbear/dropbear_rsa_host_key -p 192.168.0.202:22

$/etc/init.d/dropbear restart
Restarting Dropbear SSH server: stopped /usr/sbin/dropbear (pid 2242)
dropbear.
$ps ax |grep dropbear |grep -v grep

2276 ? Ss 0:00 /usr/sbin/dropbear -r /etc/dropbear/dropbear_rsa_host_key -p 192.168.0.202:22

[alih]

Huh, that's weird. For me, stop leads to start-stop-daemon and doesn't work:

root@om-gta02:~# start-stop-daemon -K -x dropbear
no dropbear found; none killed

That's because of this:

root@om-gta02:~# ls -lh /proc/1279/exe
lrwxrwxrwx 1 root root 0 Sep 23 00:14 /proc/1279/exe -> /usr/sbin/dropbearmulti

Busybox searches for dropbear in /proc/*/exe, but there's only dropbearmulti.

Am I right to assume that if I have the latest daily snapshot of Om2008.8, I can count it as Om2008.9? (because I didn't reflash to Om2008.9)

Are you running the commands on an actual device? I'm asking because it should have thrown your shell out upon stopping dropbear.

[julian_chu]

Hi Alih,

I always test by my own phone :-) (You can install terminal or use screen to avoid thrown by restart dropbear)

I found that why can't I reproduced the error, I use the testing repository and it use busybox-1.11.1, Om2008.9 use busybox-1.9.1.

this problem was solved in 1.11.1 (it search /proc/<pid>/cmdline but not /proc/<pid>/exe). therefore I think it was in testing but not enter stable repository yet.