Debian Bug report logs - #869182
php-common: Trouble running phpsessionclean.service on a LXC Container...

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Marco Gaiarin <gaio@sv.lnf.it>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: php-common: Trouble running phpsessionclean.service on a LXC Container...

Date: Fri, 21 Jul 2017 11:56:12 +0200

Package: php-common
Version: 1:49
Severity: normal


I've setup a LXC stretch container in a Proxmox virtualization cluster, and
after installing apache/PHP i've start to have in logs of the container rows
like:

 Jul 21 10:09:14 vglpi systemd[1]: phpsessionclean.service: Failed to reset devices.list: Operation not permitted
 Jul 21 10:09:14 vglpi systemd[24929]: phpsessionclean.service: Failed at step NETWORK spawning /usr/lib/php/sessionclean: Permission denied
 Jul 21 10:09:14 vglpi systemd[1]: phpsessionclean.service: Main process exited, code=exited, status=225/NETWORK
 Jul 21 10:09:14 vglpi systemd[1]: Failed to start Clean php session files.
 Jul 21 10:09:14 vglpi systemd[1]: phpsessionclean.service: Unit entered failed state.
 Jul 21 10:09:14 vglpi systemd[1]: phpsessionclean.service: Failed with result 'exit-code'.
 Jul 21 10:39:14 vglpi systemd[1]: phpsessionclean.service: Failed to reset devices.list: Operation not permitted
 Jul 21 10:39:14 vglpi systemd[24948]: phpsessionclean.service: Failed at step NETWORK spawning /usr/lib/php/sessionclean: Permission denied
 Jul 21 10:39:14 vglpi systemd[1]: phpsessionclean.service: Main process exited, code=exited, status=225/NETWORK
 Jul 21 10:39:14 vglpi systemd[1]: Failed to start Clean php session files.
 Jul 21 10:39:14 vglpi systemd[1]: phpsessionclean.service: Unit entered failed state.
 Jul 21 10:39:14 vglpi systemd[1]: phpsessionclean.service: Failed with result 'exit-code'.

and, on the same time, on the host that run the container:

 Jul 21 10:09:14 tessier kernel: [22515856.189072] audit: type=1400 audit(1500624554.627:384): apparmor="DENIED" operation="file_lock" profile="lxc-container-default-cgns" pid=20780 comm="(ionclean)" family="unix" sock_type="dgram" protocol=0 addr=none
 Jul 21 10:09:14 tessier kernel: [22515856.189077] audit: type=1400 audit(1500624554.627:385): apparmor="DENIED" operation="file_lock" profile="lxc-container-default-cgns" pid=20780 comm="(ionclean)" family="unix" sock_type="dgram" protocol=0 addr=none
 Jul 21 10:09:14 tessier kernel: [22515856.189082] audit: type=1400 audit(1500624554.627:386): apparmor="DENIED" operation="file_lock" profile="lxc-container-default-cgns" pid=20780 comm="(ionclean)" family="unix" sock_type="dgram" protocol=0 addr=none
 Jul 21 10:09:14 tessier kernel: [22515856.189085] audit: type=1400 audit(1500624554.627:387): apparmor="DENIED" operation="file_lock" profile="lxc-container-default-cgns" pid=20780 comm="(ionclean)" family="unix" sock_type="dgram" protocol=0 addr=none
 Jul 21 10:39:14 tessier kernel: [22517656.161803] audit: type=1400 audit(1500626354.625:388): apparmor="DENIED" operation="file_lock" profile="lxc-container-default-cgns" pid=23425 comm="(ionclean)" family="unix" sock_type="dgram" protocol=0 addr=none
 Jul 21 10:39:14 tessier kernel: [22517656.161808] audit: type=1400 audit(1500626354.625:389): apparmor="DENIED" operation="file_lock" profile="lxc-container-default-cgns" pid=23425 comm="(ionclean)" family="unix" sock_type="dgram" protocol=0 addr=none
 Jul 21 10:39:14 tessier kernel: [22517656.161812] audit: type=1400 audit(1500626354.625:390): apparmor="DENIED" operation="file_lock" profile="lxc-container-default-cgns" pid=23425 comm="(ionclean)" family="unix" sock_type="dgram" protocol=0 addr=none
 Jul 21 10:39:14 tessier kernel: [22517656.161815] audit: type=1400 audit(1500626354.625:391): apparmor="DENIED" operation="file_lock" profile="lxc-container-default-cgns" pid=23425 comm="(ionclean)" family="unix" sock_type="dgram" protocol=0 addr=none

I've tried to run the script by hand, as root, and no error appears
(on container and on host).

For now, i've disabled the service:

	root@vglpi:~# systemctl disable phpsessionclean


Thanks.

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

Kernel: Linux 4.4.21-1-pve (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages php-common depends on:
ii  init-system-helpers  1.48
ii  psmisc               22.21-2.1+b2
ii  sed                  4.4-1

php-common recommends no packages.

php-common suggests no packages.

-- no debconf information

Message #10 received at 869182@bugs.debian.org (full text, mbox, reply):

From: Chris <fisch.666@gmx.de>

To: 869182@bugs.debian.org

Subject: Re: php-common: Trouble running phpsessionclean.service on a LXC Container...

Date: Sun, 18 Feb 2018 20:14:11 +0100

Hi,

noticed the same today with unprivileged LXC Debian Stretch containers
running PHP. As a reference a possible workaround could be the following:

--------------------------
A temporary fix is:

systemctl disable phpsessionclean.timer
systemctl stop phpsessionclean.timer

Then fix the cron for operation without systemd in: /etc/cron.d/php

##09,39 *     * * *     root   [ -x /usr/lib/php/sessionclean ] && if [
! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi
09,39 *     * * *     root   [ -x /usr/lib/php/sessionclean ] &&
/usr/lib/php/sessionclean
--------------------------

Credits goes to a user from the proxmox forums here:
https://forum.proxmox.com/threads/app-armor-issues.37746/#post-198073

On Fri, 21 Jul 2017 11:56:12 +0200 Marco Gaiarin <gaio@sv.lnf.it> wrote:
> Package: php-common
> Version: 1:49
> Severity: normal
> 
> 
> I've setup a LXC stretch container in a Proxmox virtualization cluster, and
> after installing apache/PHP i've start to have in logs of the container rows
> like:
> 
>  Jul 21 10:09:14 vglpi systemd[1]: phpsessionclean.service: Failed to reset devices.list: Operation not permitted
>  Jul 21 10:09:14 vglpi systemd[24929]: phpsessionclean.service: Failed at step NETWORK spawning /usr/lib/php/sessionclean: Permission denied
>  Jul 21 10:09:14 vglpi systemd[1]: phpsessionclean.service: Main process exited, code=exited, status=225/NETWORK
>  Jul 21 10:09:14 vglpi systemd[1]: Failed to start Clean php session files.
>  Jul 21 10:09:14 vglpi systemd[1]: phpsessionclean.service: Unit entered failed state.
>  Jul 21 10:09:14 vglpi systemd[1]: phpsessionclean.service: Failed with result 'exit-code'.
>  Jul 21 10:39:14 vglpi systemd[1]: phpsessionclean.service: Failed to reset devices.list: Operation not permitted
>  Jul 21 10:39:14 vglpi systemd[24948]: phpsessionclean.service: Failed at step NETWORK spawning /usr/lib/php/sessionclean: Permission denied
>  Jul 21 10:39:14 vglpi systemd[1]: phpsessionclean.service: Main process exited, code=exited, status=225/NETWORK
>  Jul 21 10:39:14 vglpi systemd[1]: Failed to start Clean php session files.
>  Jul 21 10:39:14 vglpi systemd[1]: phpsessionclean.service: Unit entered failed state.
>  Jul 21 10:39:14 vglpi systemd[1]: phpsessionclean.service: Failed with result 'exit-code'.
> 
> and, on the same time, on the host that run the container:
> 
>  Jul 21 10:09:14 tessier kernel: [22515856.189072] audit: type=1400 audit(1500624554.627:384): apparmor="DENIED" operation="file_lock" profile="lxc-container-default-cgns" pid=20780 comm="(ionclean)" family="unix" sock_type="dgram" protocol=0 addr=none
>  Jul 21 10:09:14 tessier kernel: [22515856.189077] audit: type=1400 audit(1500624554.627:385): apparmor="DENIED" operation="file_lock" profile="lxc-container-default-cgns" pid=20780 comm="(ionclean)" family="unix" sock_type="dgram" protocol=0 addr=none
>  Jul 21 10:09:14 tessier kernel: [22515856.189082] audit: type=1400 audit(1500624554.627:386): apparmor="DENIED" operation="file_lock" profile="lxc-container-default-cgns" pid=20780 comm="(ionclean)" family="unix" sock_type="dgram" protocol=0 addr=none
>  Jul 21 10:09:14 tessier kernel: [22515856.189085] audit: type=1400 audit(1500624554.627:387): apparmor="DENIED" operation="file_lock" profile="lxc-container-default-cgns" pid=20780 comm="(ionclean)" family="unix" sock_type="dgram" protocol=0 addr=none
>  Jul 21 10:39:14 tessier kernel: [22517656.161803] audit: type=1400 audit(1500626354.625:388): apparmor="DENIED" operation="file_lock" profile="lxc-container-default-cgns" pid=23425 comm="(ionclean)" family="unix" sock_type="dgram" protocol=0 addr=none
>  Jul 21 10:39:14 tessier kernel: [22517656.161808] audit: type=1400 audit(1500626354.625:389): apparmor="DENIED" operation="file_lock" profile="lxc-container-default-cgns" pid=23425 comm="(ionclean)" family="unix" sock_type="dgram" protocol=0 addr=none
>  Jul 21 10:39:14 tessier kernel: [22517656.161812] audit: type=1400 audit(1500626354.625:390): apparmor="DENIED" operation="file_lock" profile="lxc-container-default-cgns" pid=23425 comm="(ionclean)" family="unix" sock_type="dgram" protocol=0 addr=none
>  Jul 21 10:39:14 tessier kernel: [22517656.161815] audit: type=1400 audit(1500626354.625:391): apparmor="DENIED" operation="file_lock" profile="lxc-container-default-cgns" pid=23425 comm="(ionclean)" family="unix" sock_type="dgram" protocol=0 addr=none
> 
> I've tried to run the script by hand, as root, and no error appears
> (on container and on host).
> 
> For now, i've disabled the service:
> 
> 	root@vglpi:~# systemctl disable phpsessionclean
> 
> 
> Thanks.
> 
> -- System Information:
> Debian Release: 9.0
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.4.21-1-pve (SMP w/2 CPU cores)
> Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages php-common depends on:
> ii  init-system-helpers  1.48
> ii  psmisc               22.21-2.1+b2
> ii  sed                  4.4-1
> 
> php-common recommends no packages.

Message #15 received at 869182@bugs.debian.org (full text, mbox, reply):

From: Chris <fisch.666@gmx.de>

To: 869182@bugs.debian.org

Subject: Re: php-common: Trouble running phpsessionclean.service on a LXC Container...

Date: Sun, 18 Feb 2018 21:51:23 +0100

Hi,

sorry for the follow-up in such a short time but probably just stumbled
over a possible reason for this issue:

On Fri, 21 Jul 2017 11:56:12 +0200 Marco Gaiarin <gaio@sv.lnf.it> wrote:
>  Jul 21 10:09:14 vglpi systemd[24929]: phpsessionclean.service: Failed at step NETWORK spawning /usr/lib/php/sessionclean: Permission denied

The /lib/systemd/system/phpsessionclean.service has the following entry:

PrivateNetwork=true

which is most likely causing the message quoted above on unprivileged
containers.

Message #20 received at 869182@bugs.debian.org (full text, mbox, reply):

From: Chris <fisch.666@gmx.de>

To: 869182@bugs.debian.org

Subject: Re: php-common: Trouble running phpsessionclean.service on a LXC Container...

Date: Sat, 24 Feb 2018 11:45:41 +0100

Hi again,

On Sun, 18 Feb 2018 21:51:23 +0100 Chris <fisch.666@gmx.de> wrote:
> On Fri, 21 Jul 2017 11:56:12 +0200 Marco Gaiarin <gaio@sv.lnf.it> wrote:
> >  Jul 21 10:09:14 vglpi systemd[24929]: phpsessionclean.service: Failed at step NETWORK spawning /usr/lib/php/sessionclean: Permission denied
> 
> The /lib/systemd/system/phpsessionclean.service has the following entry:
> 
> PrivateNetwork=true
> 
> which is most likely causing the message quoted above on unprivileged
> containers.

after doing some more research it seems this is already fixed in
php-common (1:60) of buster [1] but has never arrived stretch and jessie:

> php-defaults (55) unstable; urgency=medium
>
>  * Remove PrivateNetwork=true because it's not compatible with 3.16.0
>    (Debian Jessie) kernel

The source of this fix is the github issue in [2].

[1]
http://metadata.ftp-master.debian.org/changelogs/main/p/php-defaults/php-defaults_60_changelog

[2] https://github.com/oerdnj/deb.sury.org/issues/690

Message #25 received at 869182@bugs.debian.org (full text, mbox, reply):

From: Cyril Brulebois <kibi@debian.org>

To: Chris <fisch.666@gmx.de>, 869182@bugs.debian.org

Subject: Re: Bug#869182: php-common: Trouble running phpsessionclean.service on a LXC Container...

Date: Sun, 4 Mar 2018 02:51:31 +0100

[Message part 1 (text/plain, inline)]

Control: fixed -1 55
Control: severity -1 important

Hi,

Chris <fisch.666@gmx.de> (2018-02-24):
> On Sun, 18 Feb 2018 21:51:23 +0100 Chris <fisch.666@gmx.de> wrote:
> > On Fri, 21 Jul 2017 11:56:12 +0200 Marco Gaiarin <gaio@sv.lnf.it> wrote:
> > >  Jul 21 10:09:14 vglpi systemd[24929]: phpsessionclean.service: Failed at step NETWORK spawning /usr/lib/php/sessionclean: Permission denied
> > 
> > The /lib/systemd/system/phpsessionclean.service has the following entry:
> > 
> > PrivateNetwork=true
> > 
> > which is most likely causing the message quoted above on unprivileged
> > containers.
> 
> after doing some more research it seems this is already fixed in
> php-common (1:60) of buster [1] but has never arrived stretch and jessie:
> 
> > php-defaults (55) unstable; urgency=medium
> >
> >  * Remove PrivateNetwork=true because it's not compatible with 3.16.0
> >    (Debian Jessie) kernel
> 
> The source of this fix is the github issue in [2].
> 
> [1]
> http://metadata.ftp-master.debian.org/changelogs/main/p/php-defaults/php-defaults_60_changelog
> 
> [2] https://github.com/oerdnj/deb.sury.org/issues/690

Marking this bug as fixed in the aforementioned version, and adjusting
severity.

I'm not familiar enough with PHP to assess whether failing to clean up
sessions is a serious bug instead. For what it's worth: Switching the
PrivateNetwork field from true to false seems like a reasonable fix for
a stable update.


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.