Bug#800087: closed by Michael Biebl (Re: Bug#800087: systemd lists running daemons as failed after reboot)
Am 05.10.2015 um 01:48 schrieb James Bottomley: > On Sun, 2015-10-04 at 23:06 +, Debian Bug Tracking System wrote: >> Well, this is apparently an apache configuration problem, causing the >> service to return a non-zero exit code. >> >> Once you fix that, the service should not be marked as failed. > > That's pretty obviously an incorrect deduction, isn't it? If it were a > config file problem leading to the control process erroring out then the > manual systemctl start apache would also fail; but, as you can see from > the description in the original report, it doesn't. You might need to have give apache more time to start up. Maybe 20 secs is not enough since during boot there is a lot of other I/O going on and the apache control process kills itself prematurely: > Oct 03 10:45:06 bedivere apache2[693]: Starting web server: apache2AH00180: > WARNING: MaxRequestWorkers of 20 exceeds ServerLimit value of > Oct 03 10:45:06 bedivere apache2[693]: 5 servers, decreasing > MaxRequestWorkers to 5. > Oct 03 10:45:06 bedivere apache2[693]: To increase, please see the > ServerLimit directive. > Oct 03 10:45:42 bedivere apache2[693]: failed! > Oct 03 10:45:42 bedivere apache2[693]: The apache2 instance did not start > within 20 seconds. Please read the log files to discover problems ... > (warning). > Oct 03 10:45:42 bedivere systemd[1]: apache2.service: Control process exited, > code=exited status=1 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#800087: closed by Michael Biebl (Re: Bug#800087: systemd lists running daemons as failed after reboot)
Am 05.10.2015 um 10:41 schrieb Michael Biebl: > Am 05.10.2015 um 01:48 schrieb James Bottomley: >> On Sun, 2015-10-04 at 23:06 +, Debian Bug Tracking System wrote: >>> Well, this is apparently an apache configuration problem, causing the >>> service to return a non-zero exit code. >>> >>> Once you fix that, the service should not be marked as failed. >> >> That's pretty obviously an incorrect deduction, isn't it? If it were a >> config file problem leading to the control process erroring out then the >> manual systemctl start apache would also fail; but, as you can see from >> the description in the original report, it doesn't. > > You might need to have give apache more time to start up. Maybe 20 secs > is not enough since during boot there is a lot of other I/O going on and > the apache control process kills itself prematurely: > let me rephrase that: try to find out why apache does not start up properly within 20 secs (e.g. due to missing ressources) and then fix that or increase the limit. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: retitle 795494 to udev: network interfaces incorrectly named if naming rules are not in 70-persistent-net.rules
Processing commands for cont...@bugs.debian.org: > retitle 795494 udev: network interfaces incorrectly named if naming rules are > not in 70-persistent-net.rules Bug #795494 [udev] udev: network interfaces incorrectly named due to outdated initrd Changed Bug title to 'udev: network interfaces incorrectly named if naming rules are not in 70-persistent-net.rules' from 'udev: network interfaces incorrectly named due to outdated initrd' > thanks Stopping processing here. Please contact me if you need assistance. -- 795494: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795494 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#761909: (no subject)
Benedict Broy [2014-11-23 23:45 +0100]: > Hi, I have exactly the same problem. In my case, network-manager is > responsible for shutting down the network connection. Please let's keep this bug about interfaces configured with ifupdown. NM is an entirely different mechanism, and unlike ifupdown systemd isn't directly involved in that. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#761909: systemd does not unmount nfs shares before bringing down the network interface
Hello, Giuseppe Bilotta [2014-09-16 20:15 +0200]: > My fstab includes the line > > labrador:/oneforall /oneforallnfs auto,exec 0 0 > > and the nfs share is automatically mounted when a network interface that > can resolve `labrador` is brought up. I don't use NM nor wicd, so I > bring the network interfaces up myself, typically with something like: > > sudo ifup wlan0=home > > However, when the network is brought down (manually, or automatically > during system shutdown), the mountpoint is not unmounted, causing a > number of issues. This sounds very similar to https://launchpad.net/bugs/1492546 . ifupdown's /etc/init.d/networking (and also /etc/init/networking.conf) call functions check_network_file_systems() and check_network_swap() and don't tear down the interface(s) in the above situation. This also applies to e. g. iscsi. But we don't do the same with the autogenerated ifup@.service -- that always unconditionally calls "ifdown" on stopping. IMHO we should make "systemctl stop ifup@ethX.service" a no-op at least during shutdown, as stopping /etc/init.d/networking will stop them all anyway (or not, if network file systems are being used). We could change the ExecStop= to something like /bin/sh -ec '[ "$(systemctl is-system-running)" = stopping ] || /sbin/ifdown %I" Or we just declare that we don't support manual stops, and you are supposed to run "sudo ifdown ethX" to stop an interface. This is also reasonable as we consider ifup@.service more like an internal helper unit, not an user-visible/actionable one. For sure I don't want to replicate the entire check_network_file_systems()/check_network_swap() logic in ifup@.service -- running this once on shutdown is bad enough :-) Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#761909: systemd does not unmount nfs shares before bringing down the network interface
Am 05.10.2015 um 11:15 schrieb Martin Pitt: > Hello, > > Giuseppe Bilotta [2014-09-16 20:15 +0200]: >> My fstab includes the line >> >> labrador:/oneforall /oneforall nfs auto,exec 0 0 >> >> and the nfs share is automatically mounted when a network interface that >> can resolve `labrador` is brought up. I don't use NM nor wicd, so I >> bring the network interfaces up myself, typically with something like: >> >> sudo ifup wlan0=home >> >> However, when the network is brought down (manually, or automatically >> during system shutdown), the mountpoint is not unmounted, causing a >> number of issues. > > This sounds very similar to https://launchpad.net/bugs/1492546 . > ifupdown's /etc/init.d/networking (and also /etc/init/networking.conf) > call functions check_network_file_systems() and check_network_swap() > and don't tear down the interface(s) in the above situation. This also > applies to e. g. iscsi. > > But we don't do the same with the autogenerated ifup@.service -- that > always unconditionally calls "ifdown" on stopping. IMHO we should make > "systemctl stop ifup@ethX.service" a no-op at least during shutdown, > as stopping /etc/init.d/networking will stop them all anyway (or not, > if network file systems are being used). > > We could change the ExecStop= to something like > > /bin/sh -ec '[ "$(systemctl is-system-running)" = stopping ] || > /sbin/ifdown %I" > > Or we just declare that we don't support manual stops, and you are > supposed to run "sudo ifdown ethX" to stop an interface. This is also > reasonable as we consider ifup@.service more like an internal helper > unit, not an user-visible/actionable one. > > For sure I don't want to replicate the entire > check_network_file_systems()/check_network_swap() logic in > ifup@.service -- running this once on shutdown is bad enough :-) > The ifup@.service unit file has DefaultDependencies=no and *no* Conflicts=shutdown.target, which means it should *not* be stopped on shutdown. This was done this way for exactly the reason you mention. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#761909: systemd does not unmount nfs shares before bringing down the network interface
Am 05.10.2015 um 12:07 schrieb Michael Biebl: > The ifup@.service unit file has DefaultDependencies=no and *no* > Conflicts=shutdown.target, which means it should *not* be stopped on > shutdown. This was done this way for exactly the reason you mention. Originally I designed it that way: no Conflicts=shutdown.target and letting networking.service do the clean up on shutdown. ifup@.service was changed in the mean time. I wonder if the PartOf=network.target breaks that. Can someone check if ifup@.service units are stopped on shutdown? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#761909: systemd does not unmount nfs shares before bringing down the network interface
Michael Biebl [2015-10-05 12:11 +0200]: > Can someone check if ifup@.service units are stopped on shutdown? I already did this morning before I wrote that reply, they do get stopped. I added an "echo XXX; systemctl is-system-running" to ExecStop=, and I see these on shutdown. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#800947: ACL for /var/log/journal not set for group adm
Package: systemd Version: 226-4 Hi, About persistent logging, README.Debian claims : "systemd will add an ACL for read permissions for users in the "adm" group." This is not working: after creating /var/log/journal with the "install" command as instructed in the README.Debian, and even after several reboots, the ACL is not set: raph@arche:~$ getfacl /var/log/journal/ getfacl : suppression du premier « / » des noms de chemins absolus # file: var/log/journal/ # owner: root # group: systemd-journal # flags: -s- user::rwx group::r-x other::r-x Partition is ext4, so ACL are supported (I can set them manually as instructed in the README.Debian file from Jessie). Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#761909: systemd does not unmount nfs shares before bringing down the network interface
Am 05.10.2015 um 11:15 schrieb Martin Pitt: > Or we just declare that we don't support manual stops, and you are > supposed to run "sudo ifdown ethX" to stop an interface. This is also > reasonable as we consider ifup@.service more like an internal helper > unit, not an user-visible/actionable one. We bind the unit to the lifetime of the interface, i.e. we want to run ifdown $iface if the device is unplugged. So I don't think we should remove the ExecStop, at least not without making sure that this would cause regressions, like stale ifupdown state files. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#800947: ACL for /var/log/journal not set for group adm
Am 05.10.2015 um 12:26 schrieb Raphaël Halimi: > Package: systemd > Version: 226-4 > > Hi, > > About persistent logging, README.Debian claims : > > "systemd will add an ACL for read permissions for users in the "adm" group." > > This is not working: after creating /var/log/journal with the "install" > command as instructed in the README.Debian, and even after several > reboots, the ACL is not set: > > raph@arche:~$ getfacl /var/log/journal/ > getfacl : suppression du premier « / » des noms de chemins absolus > # file: var/log/journal/ > # owner: root > # group: systemd-journal > # flags: -s- > user::rwx > group::r-x > other::r-x > But the subdirectories of /var/log/journal have the correct ACL set, right? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: tagging 795494
Processing commands for cont...@bugs.debian.org: > tags 795494 + pending Bug #795494 [udev] udev: network interfaces incorrectly named if naming rules are not in 70-persistent-net.rules Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 795494: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795494 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: Re: Bug#761909: systemd does not unmount nfs shares before bringing down the network interface
Processing control commands: > tag -1 pending Bug #761909 [systemd] systemd does not unmount nfs shares before bringing down the network interface Added tag(s) pending. -- 761909: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761909 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#761909: systemd does not unmount nfs shares before bringing down the network interface
Control: tag -1 pending Hello Michael, Michael Biebl [2015-10-05 12:11 +0200]: > Originally I designed it that way: no Conflicts=shutdown.target and > letting networking.service do the clean up on shutdown. > > ifup@.service was changed in the mean time. I wonder if the > PartOf=network.target breaks that. That's indeed it! I dropped it, and ifup@*.service isn't stopped on shutdown any more. The PartOf= has a rather long history: It got introduced in 1afebb7, immediately reverted in fc63e489, and reintroduced in 3d857c21. However, with dropping the PartOf=, I just verified that "systemctl isolate emergency.target" still works fine -- as /etc/init.d/networking is stopped anyway, all interfaces get stopped, so we don't need to do that again via ifup@.service. I dont know why this didn't work back then, or it was just an oversight. But I dropped the PartOf= again in git now. Michael Biebl [2015-10-05 12:28 +0200]: > We bind the unit to the lifetime of the interface, i.e. we want to run > ifdown $iface if the device is unplugged. So I don't think we should > remove the ExecStop, at least not without making sure that this would > cause regressions, like stale ifupdown state files. Indeed. I think it's fine as it is now, you can stop it manually but it doesn't stop automatically on shutdown any more. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#800947: ACL for /var/log/journal not set for group adm
Le 05/10/2015 12:30, Michael Biebl a écrit : > But the subdirectories of /var/log/journal have the correct ACL set, right? Yes, you're right, I just noticed it; but using journalctl as a user won't display system messages (only user messages), which is not the expected behavior of adding a user in the "adm" group (pre-systemd). Maybe it's because the system.journal file doesn't have the ACL set ? raph@arche:~$ getfacl -R /var/log/journal/ getfacl : suppression du premier « / » des noms de chemins absolus # file: var/log/journal/ # owner: root # group: systemd-journal # flags: -s- user::rwx group::r-x other::r-x # file: var/log/journal//3deacfa10d0c169adfdeb36c50522bd6 # owner: root # group: systemd-journal # flags: -s- user::rwx group::r-x group:adm:r-x mask::r-x other::r-x default:user::rwx default:group::r-x default:group:adm:r-x default:mask::r-x default:other::r-x # file: var/log/journal//3deacfa10d0c169adfdeb36c50522bd6/user-1000.journal # owner: root # group: root user::rw- user:raph:r-- group::r-- mask::r-- other::--- # file: var/log/journal//3deacfa10d0c169adfdeb36c50522bd6/system.journal # owner: root # group: root user::rw- group::r-- other::--- I admit I don't know ACLs very well, but aren't the "default:..." lines supposed to mean that the files under there should have these permissions too ? Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#800947: ACL for /var/log/journal not set for group adm
Am 05.10.2015 um 13:08 schrieb Raphaël Halimi: > Le 05/10/2015 12:30, Michael Biebl a écrit : >> But the subdirectories of /var/log/journal have the correct ACL set, right? > > Yes, you're right, I just noticed it; but using journalctl as a user > won't display system messages (only user messages), which is not the > expected behavior of adding a user in the "adm" group (pre-systemd). > > Maybe it's because the system.journal file doesn't have the ACL set ? > > raph@arche:~$ getfacl -R /var/log/journal/ > getfacl : suppression du premier « / » des noms de chemins absolus > # file: var/log/journal/ > # owner: root > # group: systemd-journal > # flags: -s- > user::rwx > group::r-x > other::r-x > > # file: var/log/journal//3deacfa10d0c169adfdeb36c50522bd6 > # owner: root > # group: systemd-journal > # flags: -s- > user::rwx > group::r-x > group:adm:r-x > mask::r-x > other::r-x > default:user::rwx > default:group::r-x > default:group:adm:r-x > default:mask::r-x > default:other::r-x > > # file: var/log/journal//3deacfa10d0c169adfdeb36c50522bd6/user-1000.journal > # owner: root > # group: root > user::rw- > user:raph:r-- > group::r-- > mask::r-- > other::--- > > # file: var/log/journal//3deacfa10d0c169adfdeb36c50522bd6/system.journal > # owner: root > # group: root > user::rw- > group::r-- > other::--- > > I admit I don't know ACLs very well, but aren't the "default:..." lines > supposed to mean that the files under there should have these > permissions too ? See https://github.com/systemd/systemd/commit/8b258a645ae63dff3ab8dde6520d2e770e2a40f1 Apparently this was an intended change. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#800947: ACL for /var/log/journal not set for group adm
Am 05.10.2015 um 13:12 schrieb Michael Biebl: > Am 05.10.2015 um 13:08 schrieb Raphaël Halimi: >> Le 05/10/2015 12:30, Michael Biebl a écrit : >>> But the subdirectories of /var/log/journal have the correct ACL set, right? >> >> Yes, you're right, I just noticed it; but using journalctl as a user >> won't display system messages (only user messages), which is not the >> expected behavior of adding a user in the "adm" group (pre-systemd). >> >> Maybe it's because the system.journal file doesn't have the ACL set ? >> >> raph@arche:~$ getfacl -R /var/log/journal/ >> getfacl : suppression du premier « / » des noms de chemins absolus >> # file: var/log/journal/ >> # owner: root >> # group: systemd-journal >> # flags: -s- >> user::rwx >> group::r-x >> other::r-x >> >> # file: var/log/journal//3deacfa10d0c169adfdeb36c50522bd6 >> # owner: root >> # group: systemd-journal >> # flags: -s- >> user::rwx >> group::r-x >> group:adm:r-x >> mask::r-x >> other::r-x >> default:user::rwx >> default:group::r-x >> default:group:adm:r-x >> default:mask::r-x >> default:other::r-x >> >> # file: var/log/journal//3deacfa10d0c169adfdeb36c50522bd6/user-1000.journal >> # owner: root >> # group: root >> user::rw- >> user:raph:r-- >> group::r-- >> mask::r-- >> other::--- >> >> # file: var/log/journal//3deacfa10d0c169adfdeb36c50522bd6/system.journal >> # owner: root >> # group: root >> user::rw- >> group::r-- >> other::--- >> >> I admit I don't know ACLs very well, but aren't the "default:..." lines >> supposed to mean that the files under there should have these >> permissions too ? > > See > https://github.com/systemd/systemd/commit/8b258a645ae63dff3ab8dde6520d2e770e2a40f1 > > Apparently this was an intended change. Apparently the files were created before the ACLs have been set for /var/log/journal/3deacfa10d0c169adfdeb36c50522bd6 so the journal files that were created did not inherit the correct ACLs from the parent directory. Possibly you created /var/log/journal or set Storage=persistent, but did *not* reboot the system afterwards, which would trigger systemd-tmpfiles to be run. And once you restart systemd-journald (which can happen by systemd update), the journal files were created without the ACLs set. On next reboot, the systemd.conf tmpfile did apply the ACL for the directory, but it was too late at that point. I wonder if we should fix the documentation to tell people to run systemd-tmpfiles /usr/lib/tmpfiles/systemd.conf immediately after enabling persistent journal. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#800947: ACL for /var/log/journal not set for group adm
Am 05.10.2015 um 13:21 schrieb Michael Biebl: > I wonder if we should fix the documentation to tell people to run > systemd-tmpfiles /usr/lib/tmpfiles/systemd.conf immediately after > enabling persistent journal. We might also consider re-adding https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/debian/systemd.postinst?id=03497b4ae5418470d64f2706af795122afe9645b but maybe in a slightly modified way. Instead of running setfacl, we could use systemd-tmpfiles /usr/lib/tmpfiles.d/systemd.conf to avoid re-adding a dependency on the "acl" package. We could poke Lennart what he recommends. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#800947: ACL for /var/log/journal not set for group adm
Le 05/10/2015 13:21, Michael Biebl a écrit : > Apparently the files were created before the ACLs have been set for > /var/log/journal/3deacfa10d0c169adfdeb36c50522bd6 > so the journal files that were created did not inherit the correct ACLs > from the parent directory. > > Possibly you created /var/log/journal or set Storage=persistent, but did > *not* reboot the system afterwards, which would trigger systemd-tmpfiles > to be run. And once you restart systemd-journald (which can happen by > systemd update), the journal files were created without the ACLs set. > > On next reboot, the systemd.conf tmpfile did apply the ACL for the > directory, but it was too late at that point. No, I rebooted immediately after creating the directory. Regards, -- Raphaël Halimi signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#761909: systemd does not unmount nfs shares before bringing down the network interface
Hello On Mon, Oct 5, 2015 at 11:15 AM, Martin Pitt wrote: >> However, when the network is brought down (manually, or automatically >> during system shutdown), the mountpoint is not unmounted, causing a >> number of issues. > > This sounds very similar to https://launchpad.net/bugs/1492546 . > ifupdown's /etc/init.d/networking (and also /etc/init/networking.conf) > call functions check_network_file_systems() and check_network_swap() > and don't tear down the interface(s) in the above situation. This also > applies to e. g. iscsi. > > But we don't do the same with the autogenerated ifup@.service -- that > always unconditionally calls "ifdown" on stopping. IMHO we should make > "systemctl stop ifup@ethX.service" a no-op at least during shutdown, > as stopping /etc/init.d/networking will stop them all anyway (or not, > if network file systems are being used). Shouldn't a dependcy of network filesystems on network interfaces automatically prevet the network interfaces services from being stoppable while the network filesystems are up? -- Giuseppe "Oblomov" Bilotta ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#800965: systemd networkd profiles--wishlist
Package: systemd Version: 215 Debian GNU/Linux "JESSIE" Hi Is it possible, that a user can create custom network profiles in networkd? Like archuser do with netctl? Or any planned alternate in systemd? Greets alex signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Changing networkd's IPForward= default from "no" to "kernel"?
Hello all,
CC'ing Josh as he works with netword a lot and was rather interested
in its integration into Debian.
upstream networkd (and in Debian up to now) defaults to IPForward=no
(see man systemd.network), i. e. if you configure a network interface
through networkd without explicitly setting IPForward=, the
per-interface setting (/proc/sys/net/ipv{4,6}/conf/iface/forwarding)
will be disabled.
This has the effect that all packages which do something like "echo 1
> /proc/sys/net/ipv4/ip_forward" in their init scripts, postinst, etc.
(and we have a lot: [1]) stop working, as the per-interface setting
naturally overrides the global config.
This is a rather major issue at least for Ubuntu users with LXC, so
for now I applied a patch in Ubuntu [2] to change the default to
"kernel". The kernel's default is also to disable forwarding, but
with that packages or the admin retain the option to enable/disable
forwarding globally. I must say I don't like patching networkd, but
after discussing other possible alternatives [3] I don't see a better
way.
Is this something which we also want in Debian? My gut feeling says
"yes", but that hasn't always been correct lately :-) The alternative
is to document it something like
If you install a package that tries to enable IP forwarding, please
add "IPForward=yes" to the .network file that covers your default
route (if you aren't sure, add it to all of them). Conversely, if
you remove such a package, remove the IPForward setting again, or
change it to "no".
Aside from the fact that almost no user will actually look in
/usr/share/doc/systemd/README.Debian when this happens, this is
utterly complicated and not something which you could ever "sell"
something as a solution. I experimented with something like
/run/systemd/network/{00,zz}_enable_forwarding.network, but *.network
files aren't additive in that way, you can only ever have one that
applies to a particular interface. And changing all *.network files
programmatically from various init scripts is of course a big no-go.
So there doesn't seem to be a better way to do this right now. Ideas
muchly appreciated of course!
Opinions?
Thanks,
Martin
[1] http://codesearch.debian.net/perpackage-results/proc.*net.*ip_forward
[2]
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=ubuntu&id=2c83d8ed8e50c
[3] https://github.com/systemd/systemd/issues/1411
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
signature.asc
Description: Digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Changing networkd's IPForward= default from "no" to "kernel"?
Martin Pitt [2015-10-05 15:53 +0200]:
> I experimented with something like
> /run/systemd/network/{00,zz}_enable_forwarding.network, but
> *.network files aren't additive in that way, you can only ever have
> one that applies to a particular interface. And changing all
> *.network files programmatically from various init scripts is of
> course a big no-go.
Forgot: At some point networkd is supposed to get a D-BUS control
interface which would allow configuring devices at runtime. Once we
have that, these properties can hopefully be changed easily at
runtime, and that patch can go. But this doesn't exist yet, so we need
to change the builtin default for the time being.
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
signature.asc
Description: Digital signature
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#800947: ACL for /var/log/journal not set for group adm
Am 05.10.2015 um 13:57 schrieb Raphaël Halimi: > Le 05/10/2015 13:21, Michael Biebl a écrit : >> Apparently the files were created before the ACLs have been set for >> /var/log/journal/3deacfa10d0c169adfdeb36c50522bd6 >> so the journal files that were created did not inherit the correct ACLs >> from the parent directory. >> >> Possibly you created /var/log/journal or set Storage=persistent, but did >> *not* reboot the system afterwards, which would trigger systemd-tmpfiles >> to be run. And once you restart systemd-journald (which can happen by >> systemd update), the journal files were created without the ACLs set. >> >> On next reboot, the systemd.conf tmpfile did apply the ACL for the >> directory, but it was too late at that point. > > No, I rebooted immediately after creating the directory. Hm, right. There might be a race condition during boot, where systemd-journald-flush.service is started before systemd-tmpfiles.service. We could order systemd-journald-flush.service *after* systemd-tmpfiles.service. But, when using Storage=persistent, journald will create the directory /var/log/journal/ itself. So this won't help in that case, unless systemd-journald re-added the code to apply ACLs itself. This change sucks from a user experience POV, as you basically now need to make sure to apply the correct ACL yourself. I think the supplied ACL rule in /usr/lib/tmpfiles.d/systemd.conf is pretty much useless. Martin, any ideas? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#800965: marked as done (systemd networkd profiles--wishlist)
Your message dated Mon, 5 Oct 2015 17:24:52 +0200 with message-id <56129644.5010...@debian.org> and subject line Re: Bug#800965: systemd networkd profiles--wishlist has caused the Debian Bug report #800965, regarding systemd networkd profiles--wishlist 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.) -- 800965: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800965 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: systemd Version: 215 Debian GNU/Linux "JESSIE" Hi Is it possible, that a user can create custom network profiles in networkd? Like archuser do with netctl? Or any planned alternate in systemd? Greets alex signature.asc Description: OpenPGP digital signature --- End Message --- --- Begin Message --- Hi Am 05.10.2015 um 14:49 schrieb alex bachmer: > Package: systemd > Version: 215 > > Debian GNU/Linux "JESSIE" > > Hi > > Is it possible, that a user can create custom network profiles in > networkd? Like archuser do with netctl? > Or any planned alternate in systemd? The bug tracker is not a user support forum. Please use the Debian User mailing list for that. If you have feature requests, please raise them upstream at https://github.com/systemd/systemd/issues. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature --- End Message --- ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#800947: ACL for /var/log/journal not set for group adm
Am 05.10.2015 um 17:35 schrieb Felipe Sateler: > On 5 October 2015 at 12:20, Michael Biebl wrote: >> But, when using Storage=persistent, journald will create the directory >> /var/log/journal/ itself. So this won't help in that case, unless >> systemd-journald re-added the code to apply ACLs itself. > > That would be a bug in (upstream) systemd, I think. Journald appears > to set the ACL on new files but not on the /v/l/j directory. Are you sure? I thought systemd-journald removed that code and relies on the file system to set them. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#800947: ACL for /var/log/journal not set for group adm
On 5 October 2015 at 12:20, Michael Biebl wrote: > Am 05.10.2015 um 13:57 schrieb Raphaël Halimi: >> Le 05/10/2015 13:21, Michael Biebl a écrit : >>> Apparently the files were created before the ACLs have been set for >>> /var/log/journal/3deacfa10d0c169adfdeb36c50522bd6 >>> so the journal files that were created did not inherit the correct ACLs >>> from the parent directory. >>> >>> Possibly you created /var/log/journal or set Storage=persistent, but did >>> *not* reboot the system afterwards, which would trigger systemd-tmpfiles >>> to be run. And once you restart systemd-journald (which can happen by >>> systemd update), the journal files were created without the ACLs set. >>> >>> On next reboot, the systemd.conf tmpfile did apply the ACL for the >>> directory, but it was too late at that point. >> >> No, I rebooted immediately after creating the directory. > > Hm, right. There might be a race condition during boot, where > systemd-journald-flush.service is started before systemd-tmpfiles.service. > We could order systemd-journald-flush.service *after* > systemd-tmpfiles.service. > > But, when using Storage=persistent, journald will create the directory > /var/log/journal/ itself. So this won't help in that case, unless > systemd-journald re-added the code to apply ACLs itself. That would be a bug in (upstream) systemd, I think. Journald appears to set the ACL on new files but not on the /v/l/j directory. > > This change sucks from a user experience POV, as you basically now need > to make sure to apply the correct ACL yourself. I think the supplied ACL > rule in /usr/lib/tmpfiles.d/systemd.conf is pretty much useless. > > Martin, any ideas? I think a reasonable alternative is to ship using Storage=volatile by default, and ship the directory in the package (or create it in postinst). -- Saludos, Felipe Sateler ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#800947: ACL for /var/log/journal not set for group adm
Am 05.10.2015 um 17:20 schrieb Michael Biebl: > Hm, right. There might be a race condition during boot, where > systemd-journald-flush.service is started before systemd-tmpfiles.service. > We could order systemd-journald-flush.service *after* > systemd-tmpfiles.service. Fwiw, this directly conflicts with what is used upstream in https://github.com/systemd/systemd/blob/master/units/systemd-journal-flush.service.in#L15 [Unit] Description=Flush Journal to Persistent Storage ... Before=systemd-user-sessions.service systemd-tmpfiles-setup.service -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#800947: ACL for /var/log/journal not set for group adm
On 5 October 2015 at 12:37, Michael Biebl wrote: > Am 05.10.2015 um 17:35 schrieb Felipe Sateler: >> On 5 October 2015 at 12:20, Michael Biebl wrote: >>> But, when using Storage=persistent, journald will create the directory >>> /var/log/journal/ itself. So this won't help in that case, unless >>> systemd-journald re-added the code to apply ACLs itself. >> >> That would be a bug in (upstream) systemd, I think. Journald appears >> to set the ACL on new files but not on the /v/l/j directory. > > Are you sure? I thought systemd-journald removed that code and relies on > the file system to set them. It appears you are correct. I missed the `if (uid <= SYSTEM_UID_MAX)` check, which makes sure journald will only set acl for regular users (and thus, not the adm user), so the adm acl must be ensured by the filesystem. -- Saludos, Felipe Sateler ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
[bts-link] source package systemd
# # bts-link upstream status pull for source package systemd # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user bts-link-upstr...@lists.alioth.debian.org # remote status report for #776460 (http://bugs.debian.org/776460) # Bug title: systemd-journald crashed with SIGABRT -- killed by 1 min watchdog timeout on longer kernel lockups # * https://github.com/systemd/systemd/issues/1353 # * remote status changed: (?) -> closed # * closed upstream tags 776460 + fixed-upstream usertags 776460 + status-closed thanks ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: [bts-link] source package systemd
Processing commands for cont...@bugs.debian.org: > # > # bts-link upstream status pull for source package systemd > # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html > # > user bts-link-upstr...@lists.alioth.debian.org Setting user to bts-link-upstr...@lists.alioth.debian.org (was bts-link-de...@lists.alioth.debian.org). > # remote status report for #776460 (http://bugs.debian.org/776460) > # Bug title: systemd-journald crashed with SIGABRT -- killed by 1 min > watchdog timeout on longer kernel lockups > # * https://github.com/systemd/systemd/issues/1353 > # * remote status changed: (?) -> closed > # * closed upstream > tags 776460 + fixed-upstream Bug #776460 [systemd] systemd-journald crashed with SIGABRT -- killed by 1 min watchdog timeout on longer kernel lockups Added tag(s) fixed-upstream. > usertags 776460 + status-closed There were no usertags set. Usertags are now: status-closed. > thanks Stopping processing here. Please contact me if you need assistance. -- 776460: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776460 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Re: Changing networkd's IPForward= default from "no" to "kernel"?
On Mon, Oct 05, 2015 at 03:53:04PM +0200, Martin Pitt wrote:
> CC'ing Josh as he works with netword a lot and was rather interested
> in its integration into Debian.
Thanks, Martin.
> upstream networkd (and in Debian up to now) defaults to IPForward=no
> (see man systemd.network), i. e. if you configure a network interface
> through networkd without explicitly setting IPForward=, the
> per-interface setting (/proc/sys/net/ipv{4,6}/conf/iface/forwarding)
> will be disabled.
>
> This has the effect that all packages which do something like "echo 1
> > /proc/sys/net/ipv4/ip_forward" in their init scripts, postinst, etc.
> (and we have a lot: [1]) stop working, as the per-interface setting
> naturally overrides the global config.
>
> This is a rather major issue at least for Ubuntu users with LXC, so
> for now I applied a patch in Ubuntu [2] to change the default to
> "kernel". The kernel's default is also to disable forwarding, but
> with that packages or the admin retain the option to enable/disable
> forwarding globally. I must say I don't like patching networkd, but
> after discussing other possible alternatives [3] I don't see a better
> way.
>
> Is this something which we also want in Debian? My gut feeling says
> "yes", but that hasn't always been correct lately :-) The alternative
> is to document it something like
>
> If you install a package that tries to enable IP forwarding, please
> add "IPForward=yes" to the .network file that covers your default
> route (if you aren't sure, add it to all of them). Conversely, if
> you remove such a package, remove the IPForward setting again, or
> change it to "no".
>
> Aside from the fact that almost no user will actually look in
> /usr/share/doc/systemd/README.Debian when this happens, this is
> utterly complicated and not something which you could ever "sell"
> something as a solution. I experimented with something like
> /run/systemd/network/{00,zz}_enable_forwarding.network, but *.network
> files aren't additive in that way, you can only ever have one that
> applies to a particular interface. And changing all *.network files
> programmatically from various init scripts is of course a big no-go.
>
> So there doesn't seem to be a better way to do this right now. Ideas
> muchly appreciated of course!
As a temporary measure, while fixing the various packages doing so, this
doesn't seem too unreasonable. (Note that many of the results of that
search are comments, rather than actual scripts; nevertheless enough
instances exist to make it necessary to cope with somehow.)
However, given the potential security implications, this needs some very
clear documentation, as well as some warnings. For instance, how about
making networkd emit a warning when when the global flag is set to "yes"
but a .network file doesn't have an *explicit* IPForward setting (either
yes or no)? That would help people very quickly notice why their
packets don't get forwarded, and point them directly at the setting they
need to change. With that change, I wonder if we really need to change
the default.
I'd also be tempted to make the kernel emit a warning when setting the
global ip_forward rather than the per-interface flag, but that would
affect non-networkd users as well, and I suspect people would complain.
- Josh Triplett
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
