Bug#916179: roger-router: selecting Preferences makes the program hang

[Marc Lehmann]

On Tue, Dec 11, 2018 at 03:22:44PM +0100, Bernhard Übelacker 
 wrote:
> in that situation an strace is probably not that helpful.
> Maybe you can provide a backtrace while the program is frozen.

Sure, below are the first three traces, the first is before selecting
Preferences, the next two after. Looks to me as if it indeed seems to wait
for something pulseaudio (which isn't running).

I also noticed that I get these messages from roger the moment I select
preferences:

** (Roger Router:1367): WARNING **: 09:01:45.332: Failed to start device 
monitor!

(Roger Router:1367): Gtk-CRITICAL **: 09:01:55.877: gtk_entry_set_text: 
assertion 'text != NULL' failed

(Roger Router:1367): Gtk-CRITICAL **: 09:01:55.878: gtk_entry_set_text: 
assertion 'text != NULL' failed

 Wed Dec 12 09:01:51 CET 2018
[<0>] poll_schedule_timeout.constprop.15+0x46/0x70
[<0>] do_sys_poll+0x493/0x520
[<0>] __x64_sys_poll+0xa3/0x140
[<0>] do_syscall_64+0x5a/0x110
[<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[<0>] 0x
Attaching to process 1367
[New LWP 1368]
[New LWP 1369]
[New LWP 1371]
[New LWP 1408]
[New LWP 1414]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7fffed656739 in __GI___poll (fds=0x5607e350, nfds=14, timeout=3652) 
at ../sysdeps/unix/sysv/linux/poll.c:29
29  ../sysdeps/unix/sysv/linux/poll.c: No such file or directory.
#0  0x7fffed656739 in __GI___poll (fds=0x5607e350, nfds=14, 
timeout=3652) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x7fffede70e46 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7fffede70f6c in g_main_context_iteration () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7fffee26b13d in g_application_run () at 
/lib/x86_64-linux-gnu/libgio-2.0.so.0
#4  0x555645f3 in main (argc=1, argv=0x7fffe088) at main_ui.c:67
Detaching from program: /usr/bin/roger, process 1367
 Wed Dec 12 09:02:21 CET 2018
[<0>] poll_schedule_timeout.constprop.15+0x46/0x70
[<0>] do_sys_poll+0x493/0x520
[<0>] __x64_sys_ppoll+0x156/0x180
[<0>] do_syscall_64+0x5a/0x110
[<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[<0>] 0x
Attaching to process 1367
[New LWP 1368]
[New LWP 1369]
[New LWP 1371]
[New LWP 1414]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7fffed656836 in __GI_ppoll (fds=0x5640f9e0, nfds=1, 
timeout=, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:39
39  ../sysdeps/unix/sysv/linux/ppoll.c: No such file or directory.
#0  0x7fffed656836 in __GI_ppoll (fds=0x5640f9e0, nfds=1, 
timeout=, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:39
#1  0x7fffbf60d54d in pa_mainloop_poll () at 
/lib/x86_64-linux-gnu/libpulse.so.0
#2  0x7fffbf60db3e in pa_mainloop_iterate () at 
/lib/x86_64-linux-gnu/libpulse.so.0
#3  0x7fffbfa413d9 in pulse_audio_detect_devices () at 
/usr/lib/x86_64-linux-gnu/routermanager/pulseaudio/libpulseaudio.so
#4  0x55573219 in plugin_combobox_changed_cb (box=, 
user_data=) at pref_audio.c:74
#5  0x7fffedf50b6d in g_closure_invoke () at 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#6  0x7fffedf638f3 in  () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#7  0x7fffedf6c882 in g_signal_emit_valist () at 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#8  0x7fffedf6cecf in g_signal_emit () at 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#9  0x7fffeebb8d71 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#10 0x7fffeebbb968 in gtk_combo_box_set_active_iter () at 
/lib/x86_64-linux-gnu/libgtk-3.so.0
#11 0x7fffeebbcd01 in gtk_combo_box_set_active_id () at 
/lib/x86_64-linux-gnu/libgtk-3.so.0
#12 0x7fffedf587d0 in g_object_setv () at 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#13 0x7fffedf5971e in g_object_set_property () at 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#14 0x7fffee2d34be in  () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#15 0x7fffee2d6251 in g_settings_bind_with_mapping () at 
/lib/x86_64-linux-gnu/libgio-2.0.so.0
#16 0x7fffee2d658a in g_settings_bind () at 
/lib/x86_64-linux-gnu/libgio-2.0.so.0
#17 0x555736a2 in pref_page_audio () at pref_audio.c:168
#18 0x5557161f in preferences () at pref.c:140
#19 0x7fffedf50b6d in g_closure_invoke () at 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#20 0x7fffedf638f3 in  () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#21 0x7fffedf6c882 in g_signal_emit_valist () at 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#22 0x7fffedf6cecf in g_signal_emit () at 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#23 0x7fffee273355 in  () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#24 0x7fffeeb52f5e in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#25 0x7fffeeb52f94 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#26 0x7fffeeb52f94 in  () at /lib/x86_64-linux-gnu/libgtk-3.so.0
#27 0x7fffeeca9766 in  () at /lib/x86_64-linux-gnu/libgtk

Bug#797781: [buildd-tools-devel] Bug#797781: diffoscope does not seem to work with schroot]

[Helmut Grohne]

Hi Aurelien,

On Sun, Sep 06, 2015 at 07:28:40PM +0200, Aurelien Jarno wrote:
> The buildd flavour of the configuration mount a tmpfs in /dev/shm. AFAIK
> this is not done for the default flavour as too options are possible
> there:
> - Bind mount like above. This means sharing the shm directory with the
>   outside world. This might have some security implications, and
>   unwanted consequences.
> - Empty tmpfs like for buildds. This means the processes do not have
>   accesses to shared memory from processes outside of the chroot.
> 
> Depending on how the user want to use schroot, one or the other
> configuration should be used. I don't know how we should choose the
> default one.

Essentially, we have three options (for the default and desktop
profiles) now:

(A) Status quo: Don't mount /dev/shm.
(B) Bind mount /dev/shm.
(C) Mount a tmpfs on /dev/shm.

As you point out, each of (B) and (C) breaks some people's workflows
(either isolation or stuff doesn't work).

Either (B) or (C) fixes what many users (e.g. diffoscope, ghc, my own
itch, ...) want. (C) doesn't regress on isolation compared to (A).
Therefore I argue that (C) is strictly "better" than (A), but (B) isn't.

I agree that we cannot find a one-fits-all here. Having a comment in the
fstab for the other option certainly helps (and is already there). Still
changing the default from (A) to (C) seems like it could fix a fair
number of use cases without regressing assumptions on isolation or
existing use cases.

Does that make sense to you?

Helmut

Programme Omra Mawlid 1440 - Décembre & Janvier 2018

[Manassiki.ma]

Se désinscrire de la liste: 
http://link.envoyage.ovh/u/443/dce77af88da4405ccdba7333456af6288b5738559b6d354b

Bug#797781: [buildd-tools-devel] Bug#797781: diffoscope does not seem to work with schroot]

[Aurelien Jarno]

On 2018-12-12 10:06, Helmut Grohne wrote:
> Hi Aurelien,
> 
> On Sun, Sep 06, 2015 at 07:28:40PM +0200, Aurelien Jarno wrote:
> > The buildd flavour of the configuration mount a tmpfs in /dev/shm. AFAIK
> > this is not done for the default flavour as too options are possible
> > there:
> > - Bind mount like above. This means sharing the shm directory with the
> >   outside world. This might have some security implications, and
> >   unwanted consequences.
> > - Empty tmpfs like for buildds. This means the processes do not have
> >   accesses to shared memory from processes outside of the chroot.
> > 
> > Depending on how the user want to use schroot, one or the other
> > configuration should be used. I don't know how we should choose the
> > default one.
> 
> Essentially, we have three options (for the default and desktop
> profiles) now:
> 
> (A) Status quo: Don't mount /dev/shm.
> (B) Bind mount /dev/shm.
> (C) Mount a tmpfs on /dev/shm.
> 
> As you point out, each of (B) and (C) breaks some people's workflows
> (either isolation or stuff doesn't work).
> 
> Either (B) or (C) fixes what many users (e.g. diffoscope, ghc, my own
> itch, ...) want. (C) doesn't regress on isolation compared to (A).
> Therefore I argue that (C) is strictly "better" than (A), but (B) isn't.

(C) might give users the possibility to trigger an OOM and DoS system.
/dev/shm is writable by any user. If users have no limit on the number
of chroots they can run, they might be able to fill the whole memory
(RAM + swap), leading to an OOM, potentially killing essential services
as the memory from a tmpfs can't be killed. This does not happen on a
normal system, as the default size of a tmpfs is half of the size of the
RAM.

So I am not sure that (C) is "strictly better".

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#797781: [buildd-tools-devel] Bug#797781: diffoscope does not seem to work with schroot]

[Roger Leigh]

On 12/12/2018 15:25, Aurelien Jarno wrote:

On 2018-12-12 10:06, Helmut Grohne wrote:

Hi Aurelien,

On Sun, Sep 06, 2015 at 07:28:40PM +0200, Aurelien Jarno wrote:

The buildd flavour of the configuration mount a tmpfs in /dev/shm. AFAIK
this is not done for the default flavour as too options are possible
there:
- Bind mount like above. This means sharing the shm directory with the
   outside world. This might have some security implications, and
   unwanted consequences.
- Empty tmpfs like for buildds. This means the processes do not have
   accesses to shared memory from processes outside of the chroot.

Depending on how the user want to use schroot, one or the other
configuration should be used. I don't know how we should choose the
default one.


Essentially, we have three options (for the default and desktop
profiles) now:

(A) Status quo: Don't mount /dev/shm.
(B) Bind mount /dev/shm.
(C) Mount a tmpfs on /dev/shm.

As you point out, each of (B) and (C) breaks some people's workflows
(either isolation or stuff doesn't work).

Either (B) or (C) fixes what many users (e.g. diffoscope, ghc, my own
itch, ...) want. (C) doesn't regress on isolation compared to (A).
Therefore I argue that (C) is strictly "better" than (A), but (B) isn't.


(C) might give users the possibility to trigger an OOM and DoS system.
/dev/shm is writable by any user. If users have no limit on the number
of chroots they can run, they might be able to fill the whole memory
(RAM + swap), leading to an OOM, potentially killing essential services
as the memory from a tmpfs can't be killed. This does not happen on a
normal system, as the default size of a tmpfs is half of the size of the
RAM.

So I am not sure that (C) is "strictly better".


It should perhaps be combined with some sensible default size 
limitations like we used to provide in (IIRC) /etc/default/tmpfs.


For the (B) case, do we have any defined use case for sharing shm 
between host and chroot?  It's useless for anonymous (unlinked) 
mappings, because they won't be propagated.  So the only use case is 
named mappings.  If we don't have any concrete use case for that, I'd be 
tempted to drop this possibility entirely.


For (A) if you don't mount /dev/shm, is there still some risk due to 
using the underlying devtmpfs mount and causing problems, including 
security problems, as a result?  You might still get shared data between 
host and chroots stored there, which might have security and privacy 
implications?  And you could affect the /dev mountpoint if using all the 
space prevents device node or other file creation under /dev on the host?


I think (C) is vastly preferable from the security point of view. 
However, it does as you point out, have problems if you overcommit 
resources across multiple chroots.


One possible mitigation would be to not mount a tmpfs at all.  There is 
no technical requirement that /dev/shm be a tmpfs.  It could be backed 
by disk, e.g. creating and bind mounting chroot/shm to chroot/dev/shm 
would make it use the same disc backing as the chroot itself.  Or create 
a session-specific private dir under [/var]/tmp and bind mount that (it 
will avoid serialising and storing session state for source chroots). 
There will of course be a potential performance cost in using a real 
disc, but it takes all of the resource exhaustion and privacy questions 
completely out of the picture.



Regards,
Roger

Bug#774644: marked as done ((re)starting lighttpd should not report OK when it fails to start)

[Debian Bug Tracking System]

Your message dated Wed, 12 Dec 2018 23:33:24 -0500
with message-id <20181213043324.ga8...@i5.lan>
and subject line 774644-done
has caused the Debian Bug report #774644,
regarding (re)starting lighttpd should not report OK when it fails to start
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
774644: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774644
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: lighttpd
Version: 1.4.31-4+deb7u3
Severity: important

A simple dependency fix, lighttpd package should simply add a dependency for
php5-cgi

Also reported almost 7 years ago against Ubuntu at
https://bugs.launchpad.net/ubuntu/+source/lighttpd/+bug/236027

To reproduce:

install lighttpd WITHOUT php5-cgi package installed

run:

# lighttpd-enable-mod

enter fastcgi-php and exit

reload lighttpd configuration or restart lighttpd

# service lighttpd restart

Normal output is shown, suggesting server is started successfully

Server is not actually started, /var/log/lighttpd/error.log shows:

2015-01-05 12:25:35: (log.c.166) server started
2015-01-05 12:25:35: (mod_fastcgi.c.1103) the fastcgi-backend /usr/bin/php-cgi
failed to start:
2015-01-05 12:25:35: (mod_fastcgi.c.1107) child exited with status 2 /usr/bin
/php-cgi
2015-01-05 12:25:35: (mod_fastcgi.c.1110) If you're trying to run your app as a
FastCGI backend, make sure you're using the FastCGI-enabled version.
If this is PHP on Gentoo, add 'fastcgi' to the USE flags.
2015-01-05 12:25:35: (mod_fastcgi.c.1397) [ERROR]: spawning fcgi failed.
2015-01-05 12:25:35: (server.c.976) Configuration of plugins failed. Going
down.

Installing package "php5-cgi" corrects the issue.



-- System Information:
Debian Release: 7.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
'stable'), (300, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lighttpd depends on:
ii  libattr11:2.4.46-8
ii  libbz2-1.0  1.0.6-4
ii  libc6   2.13-38+deb7u6
ii  libfam0 2.7.0-17
ii  libldap-2.4-2   2.4.31-1+nmu2
ii  libpcre31:8.30-5
ii  libssl1.0.0 1.0.1e-2+deb7u13
ii  libterm-readline-perl-perl  1.0303-1
ii  lsb-base4.1+Debian8+deb7u1
ii  mime-support3.52-1+deb7u1
ii  perl5.14.2-21+deb7u2
ii  zlib1g  1:1.2.7.dfsg-13

Versions of packages lighttpd recommends:
ii  spawn-fcgi  1.6.3-1

Versions of packages lighttpd suggests:
ii  apache2-utils  2.2.22-13+deb7u3
ii  openssl1.0.1e-2+deb7u13
pn  rrdtool

-- no debconf information
--- End Message ---
--- Begin Message ---
Package: lighttpd
Version: lighttpd/1.4.49-1

fixed upstream in lighttpd 1.4.46--- End Message ---

Bug#907682: marked as done (lighttpd: segfault / error 4; primarily when accessing fastcgi/php)

[Debian Bug Tracking System]

Your message dated Wed, 12 Dec 2018 23:41:20 -0500
with message-id <20181213044120.gb8...@i5.lan>
and subject line 907682-done
has caused the Debian Bug report #907682,
regarding lighttpd: segfault / error 4; primarily when accessing fastcgi/php
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
907682: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907682
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: lighttpd
Version: 1.4.49-1.1
Severity: important

I upgraded today:
[UPGRADE] lighttpd:amd64 1.4.45-1 -> 1.4.49-1.1
[UPGRADE] lighttpd-mod-magnet:amd64 1.4.45-1 -> 1.4.49-1.1

and now I get a segfault within 30 seconds of startup.  When I run lighttpd via 
"strace lighttpd -D -f ..." it appears to crash when accessing php via fastcgi,
though I think it can access simple PHP scripts without crashing, so perhaps it
is on the php side, though when I downgrade back to 1.4.45, everything is fine.

The exact error message is (one per server instantiation):
Aug 31 05:22:22 tangelo kernel: [10595636.459818] lighttpd[8657]: segfault at 
b0 ip 55a286a8919a sp 7ffdee39f000 error 4 in 
lighttpd[55a286a64000+46000]
Aug 31 05:23:27 tangelo kernel: [10595701.465898] lighttpd[8868]: segfault at 
b0 ip 563eb738819a sp 7ffc7b968290 error 4 in 
lighttpd[563eb7363000+46000]
Aug 31 05:27:19 tangelo kernel: [10595932.776978] lighttpd[9176]: segfault at 
b0 ip 55c975b0619a sp 7ffef9652fe0 error 4 in 
lighttpd[55c975ae1000+46000]
Aug 31 05:34:10 tangelo kernel: [10596343.912608] lighttpd[10534]: segfault at 
b0 ip 556ff121c19a sp 7ffd94a20570 error 4 in 
lighttpd[556ff11f7000+46000]

The access is not logged in /var/log/lighttpd/, and no errors reported there, 
just the segfault in /var/log/messages.

Any ideas about where I should look?

I'm using PHP 5.6.22-2 (cgi-fcgi), so perhaps that just isn't supported any 
more.


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.13.0-1-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages lighttpd depends on:
ii  init-system-helpers  1.54
ii  libattr1 1:2.4.47-2+b2
ii  libbz2-1.0   1.0.6-9
ii  libc62.27-5
ii  libgamin0 [libfam0]  0.1.10-5+b1
ii  libpcre3 2:8.39-11
ii  libssl1.11.1.0h-4
ii  lsb-base 9.20170808
ii  mime-support 3.61
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages lighttpd recommends:
ii  spawn-fcgi  1.6.4-2

Versions of packages lighttpd suggests:
pn  apache2-utils  
pn  lighttpd-doc   
ii  openssl1.1.0h-4
ii  php5-cgi   5.6.22+dfsg-2
pn  rrdtool

-- Configuration Files:
/etc/lighttpd/conf-available/10-accesslog.conf changed:
server.modules += ( "mod_accesslog" )

/etc/lighttpd/conf-available/10-cgi.conf changed:
server.modules += ( "mod_cgi" )
$HTTP["url"] =~ "^/cgi-bin/" {
cgi.assign = ( ".cgi" => "" )
}

/etc/lighttpd/conf-available/10-evasive.conf changed:
server.modules += ( "mod_evasive" )
evasive.max-conns-per-ip = 150

/etc/lighttpd/conf-available/10-fastcgi.conf changed:
server.modules += ( "mod_fastcgi" )
fastcgi.server= ( ".php" => 
((
"bin-path" => "/usr/bin/php-cgi",
"socket" => "/tmp/php.socket",
"max-procs" => 5,
"idle-timeout" => 5,
"bin-environment" => ( 
"PHP_FCGI_CHILDREN" => "30",
"PHP_FCGI_MAX_REQUESTS" => "500"
),
"bin-copy-environment" => (
"PATH", "SHELL", "USER"
),
"broken-scriptfilename" => "enable"
))
)

/etc/lighttpd/lighttpd.conf changed:
server.modules = (
"mod_access",
"mod_alias",
"mod_compress",
"mod_rewrite",
"mod_redirect",
"mod_expire",
)
include_shell "/usr/share/lighttpd/include-conf-enabled.pl"
server.max-keep-alive-requests = 32
server.max-keep-alive-idle = 5
server.max-read-idle = 30
server.max-write-idle = 30
server.max-fds = 2048
server.max-connections = 1024
server.event-handler = "linux-sysepoll"
server.network-backend = "linux-sendfile"
server.stat-cache-engine = "fam"


-- no debconf information
--- End Message ---
--- Begin Message ---
Package: lighttpd
Version: lighttpd/1.4.52-1

believed fixed upstream in light

Bug#907825: marked as done (lighttpd : scripts in /cgi-bin are not executed, Error 404)

[Debian Bug Tracking System]

Your message dated Wed, 12 Dec 2018 23:44:42 -0500
with message-id <2018121302.gc8...@i5.lan>
and subject line 907825-done
has caused the Debian Bug report #907825,
regarding lighttpd : scripts in /cgi-bin are not executed, Error 404
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
907825: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907825
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package:lighttpd
Version:stable,now 1.4.45-1 amd64 [installed]

OS : Debian GNU/Linux 9.5 (stretch)

I have installed lighttpd, if i do : http:///index.html it is
working as expected.
Then i have enabled CGI : sudo lighttpd-enable-mod cgi
i have place a simple "hello.py" (chmod +x) in /usr/lib/cgi-bin
http:///cgi-bin/hello.py gives a 404 Error

i have edit the "/etc/lighttpd/conf-enabled/10-cgi.conf" file :

# /usr/share/doc/lighttpd/cgi.txt

server.modules += ( "mod_cgi" )

$HTTP["url"] =~ "^/cgi-bin/" {
alias.url += ( "/cgi-bin/" => "/var/www/cgi-bin" )
cgi.assign = (
".py"  => "/usr/bin/python",
)
}

i have make a directory "cgi-bin" in /var/www and place the hello.py there
http:///cgi-bin/hello.py gives Error 404

Really frustrating, im out of ideas how to solve this.

-- 
   \\\//
  -(o o)-
 ==oOO==(_)==OOo==
 Andrzej Więckowski
 andw...@gmail.com
--- End Message ---
--- Begin Message ---
Package: lighttpd
Version: lighttpd/1.4.45-1

user error

Use:
alias.url += ( "/cgi-bin/" => "/var/www/cgi-bin/" )

Note the trailing slashes on both pieces of the alias.

/var/www/cgi-binhello.py is unlikely to exist, resulting
in 404 Not Found, whereas /var/www/cgi-bin/hello.py exists.--- End Message ---

Bug#850061: marked as done (lighttpd: should support reloading configuration without restarting)

[Debian Bug Tracking System]

Your message dated Thu, 13 Dec 2018 00:02:12 -0500
with message-id <20181213050212.ga7...@i5.lan>
and subject line 838473-done
has caused the Debian Bug report #838473,
regarding lighttpd: should support reloading configuration without restarting
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
838473: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838473
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: lighttpd
Version: 1.4.43+git20161216-1
Severity: minor

Dear Maintainer,

The way lighttpd is packaged by Debian does not seem to make it possible to
reload lighttd's configuration without restarting it (terminating any ongoing
client connections).

Specifically, sending SIGHUP to lighttpd does not appear to make it reload its
configuration, and running systemctl force-reload lighttpd.service makes it
restart, which kills ongoing connections.

I think it would be preferable to run lighttpd using the lighttpd-angel program
(which is part of the lighttpd distribution, and also shipped by Debian), which
makes it possible to restart a new lighttpd with the new configuration while
leaving the old one around to finish handling ongoing connections.

More information:



Using lighttpd-angel, it should be possible to ask lighttpd to reload its
configuration without terminating ongoing connections.

Thanks!


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'experimental'), (600, 'unstable'), (500, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lighttpd depends on:
ii  init-system-helpers  1.46
ii  libattr1 1:2.4.47-2
ii  libbz2-1.0   1.0.6-8
ii  libc62.24-8
ii  libfam0  2.7.0-17.2
ii  libpcre3 2:8.39-2
ii  libssl1.11.1.0c-2
ii  lsb-base 9.20161125
ii  mime-support 3.60
ii  zlib1g   1:1.2.8.dfsg-4

Versions of packages lighttpd recommends:
ii  spawn-fcgi  1.6.4-1

Versions of packages lighttpd suggests:
ii  apache2-utils  2.4.25-1
pn  lighttpd-doc   
ii  openssl1.1.0c-2
pn  php5-cgi   
pn  rrdtool

-- Configuration Files:
/etc/lighttpd/lighttpd.conf changed [not included]

-- no debconf information
--- End Message ---
--- Begin Message ---
Package: lighttpd
Version: lighttpd/1.4.49-1

fixed upstream in lighttpd 1.4.46--- End Message ---

Bug#877870: marked as done (lighttpd: "reload" action breaks further actions)

[Debian Bug Tracking System]

Your message dated Thu, 13 Dec 2018 00:02:12 -0500
with message-id <20181213050212.ga7...@i5.lan>
and subject line 838473-done
has caused the Debian Bug report #838473,
regarding lighttpd: "reload" action breaks further actions
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
838473: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838473
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: lighttpd
Version: 1.4.45-1
Severity: normal

Dear Maintainer,

After you issue a "service lighttpd reload" (or call /etc/init.d/lighttpd
directly with the same action), all further actions stop working.

This happens because the "reload" action is not defined in the systemd
service file, so the code in /etc/init.d/lighttpd is used. That code in
turn restarts the service. When you later run status/stop/start/restart,
these are done via systemd and it thinks the service is dead because the
PID changed.

For example, starting with a running lighttpd:
root@sid-lighttpd-reload-1721635:~# ps fxaw
  PID TTY  STAT   TIME COMMAND
(...)
17184 ?Ss 0:00 /usr/sbin/lighttpd -D -f
/etc/lighttpd/lighttpd.conf
root@sid-lighttpd-reload-1721635:~# service lighttpd status
● lighttpd.service - Lighttpd Daemon
   Loaded: loaded (/lib/systemd/system/lighttpd.service; enabled; vendor
preset: enabled)
   Active: active (running) since Fri 2017-10-06 13:48:53 UTC; 4s ago
(...)

Let's reload:
root@sid-lighttpd-reload-1721635:~# service lighttpd reload
[ ok ] Reloading web server configuration: lighttpd.

Status now is dead:
root@sid-lighttpd-reload-1721635:~# service lighttpd status
● lighttpd.service - Lighttpd Daemon
   Loaded: loaded (/lib/systemd/system/lighttpd.service; enabled; vendor
preset: enabled)
   Active: inactive (dead) since Fri 2017-10-06 13:49:08 UTC; 2s ago
  Process: 17184 ExecStart=/usr/sbin/lighttpd -D -f
/etc/lighttpd/lighttpd.conf (code=exited, status=0/SUCCESS)
  Process: 17177 ExecStartPre=/usr/sbin/lighttpd -tt -f
/etc/lighttpd/lighttpd.conf (code=exited, status=0/SUCCESS)
 Main PID: 17184 (code=exited, status=0/SUCCESS)

But it's still running, albeit a new copy:
root@sid-lighttpd-reload-1721635:~# ps fxaw
  PID TTY  STAT   TIME COMMAND
(...)
17231 ?S  0:00 /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf

"start" will fail now, for example:
root@sid-lighttpd-reload-1721635:~# service lighttpd status
● lighttpd.service - Lighttpd Daemon
   Loaded: loaded (/lib/systemd/system/lighttpd.service; enabled; vendor
preset: enabled)
   Active: failed (Result: exit-code) since Fri 2017-10-06 13:51:25 UTC;
836ms ago
  Process: 17391 ExecStart=/usr/sbin/lighttpd -D -f
/etc/lighttpd/lighttpd.conf (code=exited, status=255)
  Process: 17384 ExecStartPre=/usr/sbin/lighttpd -tt -f
/etc/lighttpd/lighttpd.conf (code=exited, status=0/SUCCESS)
 Main PID: 17391 (code=exited, status=255)

Oct 06 13:51:25 sid-lighttpd-reload-1721635 systemd[1]: lighttpd.service:
Unit entered failed state.
Oct 06 13:51:25 sid-lighttpd-reload-1721635 systemd[1]: lighttpd.service:
Failed with result 'exit-code'.

journalctl shows the reason:
Oct 06 13:51:24 sid-lighttpd-reload-1721635 lighttpd[17377]: 2017-10-06
13:51:24: (network.c.464) can't bind to port:  80 Address already in use

Managing this service via systemd or sysv is now effectively broken.
--- End Message ---
--- Begin Message ---
Package: lighttpd
Version: lighttpd/1.4.49-1

fixed upstream in lighttpd 1.4.46--- End Message ---

Bug#838473: marked as done (lighttpd: Not reliably stoppable using systemd service file)

[Debian Bug Tracking System]

Your message dated Thu, 13 Dec 2018 00:02:12 -0500
with message-id <20181213050212.ga7...@i5.lan>
and subject line 838473-done
has caused the Debian Bug report #838473,
regarding lighttpd: Not reliably stoppable using systemd service file
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
838473: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838473
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: lighttpd
Version: 1.4.35-4+deb8u1
Severity: normal

When running 'systemctl stop lighttpd', sometimes the command will seemingly
complete successfully, but doesn't actually stop lighttpd. Similarly, after
'systemctl restart lighttpd' the same instance will just continue running
(as the old one isn't stopped and systemd's attempt to start lighttpd
again obviously fails as the ports are in use).

I haven't properly debugged this issue in any way, but I've seen it across
various servers using lighttpd. My first guess for the cause would be 
that no pidfile is specified in the systemd service and systemd is left guessing
for the main task, but I could be wrong.


-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set 
LC_ALL to default locale: No such file or directory
UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lighttpd depends on:
ii  init-system-helpers 1.22
ii  libattr11:2.4.47-2
ii  libbz2-1.0  1.0.6-7+b3
ii  libc6   2.19-18+deb8u4
ii  libfam0 2.7.0-17.1
ii  libldap-2.4-2   2.4.40+dfsg-1+deb8u2
ii  libpcre32:8.35-3.3+deb8u4
ii  libssl1.0.0 1.0.2h-1~bpo8+2
ii  libterm-readline-perl-perl  1.0303-1
ii  lsb-base4.1+Debian13+nmu1
ii  mime-support3.58
ii  perl5.20.2-3+deb8u6
ii  systemd 215-17+deb8u4
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages lighttpd recommends:
ii  spawn-fcgi  1.6.4-1

Versions of packages lighttpd suggests:
pn  apache2-utils  
ii  openssl1.0.1t-1+deb8u2
pn  rrdtool

-- Configuration Files:
/etc/lighttpd/lighttpd.conf changed [not included]

-- debconf information excluded
--- End Message ---
--- Begin Message ---
Package: lighttpd
Version: lighttpd/1.4.49-1

fixed upstream in lighttpd 1.4.46--- End Message ---

Bug#916329: pngmeta FTCBFS: builds for the wrong architecture

[Helmut Grohne]

Source: pngmeta
Version: 1.11-9
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

pngmeta fails to cross build from source, because it configures for the
build architecture. The packaging does pass the relevant --host flag to
./configure, but ./configure is too old to recognize it. One should pass
a suitable CC here instead. Please consider applying the attached patch.

Helmut
diff -u pngmeta-1.11/debian/changelog pngmeta-1.11/debian/changelog
--- pngmeta-1.11/debian/changelog
+++ pngmeta-1.11/debian/changelog
@@ -1,3 +1,10 @@
+pngmeta (1.11-9.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass CC to ./configure rather than --host. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 13 Dec 2018 07:17:18 +0100
+
 pngmeta (1.11-9) unstable; urgency=medium
 
   * QA upload.
diff -u pngmeta-1.11/debian/rules pngmeta-1.11/debian/rules
--- pngmeta-1.11/debian/rules
+++ pngmeta-1.11/debian/rules
@@ -1,19 +1,13 @@
 #!/usr/bin/make -f
 #export DH_VERBOSE=1
 
-# These are used for cross-compiling and for saving the configure script
-# from having to guess our platform (since we know it already)
-DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
-DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
-
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk
+-include /usr/share/dpkg/buildtools.mk
 
 config.status: configure
dh_testdir
-   ./configure \
-   --host=$(DEB_HOST_GNU_TYPE) \
-   --build=$(DEB_BUILD_GNU_TYPE) \
+   CC=$(CC) ./configure \
--prefix=/usr --mandir=\$${prefix}/share/man \
--infodir=\$${prefix}/share/info