Bug#787731: adds google nameserver without being asked to
Am 09.06.2015 um 13:14 schrieb Marc Haber: > On Sat, Jun 06, 2015 at 09:42:37PM +0200, Michael Biebl wrote: >> This change is imho too invasive for being backported to the stable v215 >> in jessie. The first Debian version carrying that fix is 217-1, so I'm >> closing it for this version. > > How about shipping a /etc/systemd/resolved.conf with a not commented > out "DNS=" line? Compiling with ---with-dns-servers="" is better. It doesn't require us to patch the conf file, it also changes the builtin list, and the resulting resolved.conf will actually look pretty similar: [Resolve] #DNS= -- 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#783509: me too :)
Hello, just writing to add that I am having the same problem and /tmp silently became mounted on tmpfs with no warnings and no entries on changelogs. This caused a few hard resets, that I could not explain, because I normally download films into /tmp and then watch them. So I think that right now, this has the potential to cause some unforseen distruption in systems that assume /tmp is on disk. Best -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/ ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Packaging issue: .service files are no conffiles (due to /lib) while init scripts are conffiles and hence remain longer on the system upon package removal without purging
Hi, there seem to be a general issue with how .service files should be packaged (in /lib/systemd/system/ and not in /etc/systemd/system/): If a package is shipping a init script as well as a service file (as currently strongly recommend), it's usually the case that the init script is left on the system upon package removal without also purging its conffiles. While this is no issue at all with sysvinit, it seems to cause issues with systemd's sysvinit compatibility mode because the init script is still there but the overriding .service file is already removed. :-/ Example case where this causes ordering cycle issues: https://bugs.launchpad.net/ubuntu/+source/screen/+bug/1462692 The bug report above contains two suggested solutions: 1) Ship the .service file in /etc/systemd/system/ instead of /lib/systemd/system/ so that it's removed at the same time as the init script and override the according lintian warning. Example implementation: https://anonscm.debian.org/cgit/collab-maint/screen.git/commit/?id=f7d8704dc Advantage: dead-simple and fail-safe Disadvantage: Overriding a lintian warning. Additionally, in this specific case (a symlink to /dev/null to make systemd ignore the init script), a file which better should not be changed by the local admin would be put under /etc/. Then again, there's not much which the local admin could change, so it shouldn't really hurt. 2) Don't ship the /lib/systemd/system/screen-cleanup.service link (possibly a less general solution) in the .deb, but create it in postinst and remove it in the postrm on purge. Advantage: No lintian warning, no file under /etc/. Disadvantage: Error-prone due to more complexity in the maintainer scripts -- which I'd like to avoid. Is there any simpler or maybe even already supported way to solve or avoid such issues? I'd expect that screen is not the only package where users run into such issues. E.g. is there a chance that systemd's sysvinit compatibility mode ignores (wrt. dependency ordering/resolving) any init script where the owning package is removed, but not yet purged? I've also looked into all files in /lib/lsb/init-functions.d/ on a desktop system running systemd as init system, but nothing in there seems to be related to dependency resolving. Also dh_installinit(1) currently doesn't seem to cover that topic. P.S.: I'm not on the list, so please at least Cc me when replying. Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ 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: Packaging issue: .service files are no conffiles (due to /lib) while init scripts are conffiles and hence remain longer on the system upon package removal without purging
Hey Axel, all, thanks for raising that on the list. Axel Beckert [2015-06-10 12:22 +0200]: > 1) Ship the .service file in /etc/systemd/system/ instead of >/lib/systemd/system/ so that it's removed at the same time as the >init script and override the according lintian warning. I don't believe that package defaults should go into /etc at all (/etc/init.d/ is a really bad idea), so this would only make it worse. > 2) Don't ship the /lib/systemd/system/screen-cleanup.service link >(possibly a less general solution) in the .deb, but create it in >postinst and remove it in the postrm on purge. I suggested that as a short-term local workaround in the package. I like that better than cluttering /etc/, and it should have the same effect. >Disadvantage: Error-prone due to more complexity in the >maintainer scripts -- which I'd like to avoid. Yes, absolutely. Should that become the official solution, this should be debhelper'ed somehow. > Is there any simpler or maybe even already supported way to solve or > avoid such issues? I'd expect that screen is not the only package > where users run into such issues. I'm not aware of any. However, it doesn't actually affect too many packages: this is mostly an issue for rcS init.d scripts, which often have very heavy (and often principally unsatisfiable) dependencies, such as setserial in #786976. rcS scripts which depend on $remote_fs are generally a pain (and don't work under sysvinit either if you use /var on NFS or similar, it's just that the error is mostly hidden there). > E.g. is there a chance that systemd's sysvinit compatibility mode > ignores (wrt. dependency ordering/resolving) any init script where the > owning package is removed, but not yet purged? Determining that for any init script is prohibitively expensive, we can't do that in generators. I. e. we don't want to impose doing expensive dpkg calls dozens of times on every boot. The main problem is that init.d scripts have no declarative way of telling you which package they belong to, so you'd need to do something like dpkg -S. There is also no robust way to identify a "daemon path" or similar (whose existence we could then test), as init.d scripts often don't start daemons at all (like in this /e/i/screen-cleanup case). The main design problem here is that removing, but not purging, a package leaves the init.d script, and worse, leaves it enabled. (i. e. the enabling symlinks in /etc/rc?.d/ all stay in place). That means that such init scripts run *even* if the package they belong to is removed. Again, the ones starting a daemon usually test if that daemon actually exists, for that very reason. But the ones which do "one-shot" like stuff might not. This isn't something which we can easily/cheaply determine and workaround in the sysv-generator; it affects sysvinit all the same. One option would be to "update-rc.d disable" init scripts on removal, not purge (but then we'd lose the rc[2-5].d/ symlink structure, which is still considered "admin config"). Or removing a package needs to set an additional flag etc. which signals init to not run that file. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ 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: Packaging issue: .service files are no conffiles (due to /lib) while init scripts are conffiles and hence remain longer on the system upon package removal without purging
Am 10.06.2015 um 12:22 schrieb Axel Beckert: > Hi, > > there seem to be a general issue with how .service files should be > packaged (in /lib/systemd/system/ and not in /etc/systemd/system/): > > If a package is shipping a init script as well as a service file (as > currently strongly recommend), it's usually the case that the init > script is left on the system upon package removal without also purging > its conffiles. > > While this is no issue at all with sysvinit, it seems to cause issues > with systemd's sysvinit compatibility mode because the init > script is still there but the overriding .service file is already > removed. :-/ > > Example case where this causes ordering cycle issues: > https://bugs.launchpad.net/ubuntu/+source/screen/+bug/1462692 > > The bug report above contains two suggested solutions: > > 1) Ship the .service file in /etc/systemd/system/ instead of >/lib/systemd/system/ so that it's removed at the same time as the >init script and override the according lintian warning. > >Example implementation: > > https://anonscm.debian.org/cgit/collab-maint/screen.git/commit/?id=f7d8704dc > >Advantage: dead-simple and fail-safe > >Disadvantage: Overriding a lintian warning. > >Additionally, in this specific case (a symlink to /dev/null to make >systemd ignore the init script), a file which better should not be >changed by the local admin would be put under /etc/. Then again, >there's not much which the local admin could change, so it >shouldn't really hurt. Please don't do this. /etc/systemd is strictly admin territory. > 2) Don't ship the /lib/systemd/system/screen-cleanup.service link >(possibly a less general solution) in the .deb, but create it in >postinst and remove it in the postrm on purge. > >Advantage: No lintian warning, no file under /etc/. > >Disadvantage: Error-prone due to more complexity in the >maintainer scripts -- which I'd like to avoid. This one doesn't look ok either. > > Is there any simpler or maybe even already supported way to solve or > avoid such issues? I'd expect that screen is not the only package > where users run into such issues. > The underlying problem, as you noticed, is that sysv init scripts are treated as conffiles. Imho this is arguably a bug, but it's too late to fix that. To address this, we added code do dh_systemd, to mask the service on remove. So even if the package is only removed, but not purged, be remaining sysv init script will not be considered by systemd. This mask is removed on purge. If you use dh_systemd, you'll get that integration for free, and I'd suggest you use that, otherwise, you'll have to do the mask/unmask steps manually. -- 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
Re: Packaging issue: .service files are no conffiles (due to /lib) while init scripts are conffiles and hence remain longer on the system upon package removal without purging
Michael Biebl [2015-06-10 12:50 +0200]: > To address this, we added code do dh_systemd, to mask the service on > remove. So even if the package is only removed, but not purged, be > remaining sysv init script will not be considered by systemd. > This mask is removed on purge. Oh, thanks for pointing out! Seems I forgot about that one. So we already have the debhelperization for this, nice :-) 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
Re: Packaging issue: .service files are no conffiles (due to /lib) while init scripts are conffiles and hence remain longer on the system upon package removal without purging
Am 10.06.2015 um 12:54 schrieb Martin Pitt: > Michael Biebl [2015-06-10 12:50 +0200]: >> To address this, we added code do dh_systemd, to mask the service on >> remove. So even if the package is only removed, but not purged, be >> remaining sysv init script will not be considered by systemd. >> This mask is removed on purge. > > Oh, thanks for pointing out! Seems I forgot about that one. So we > already have the debhelperization for this, nice :-) And you should use dh_systemd anyway, to properly enable the service on installation. -- 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
Re: Packaging issue: .service files are no conffiles (due to /lib) while init scripts are conffiles and hence remain longer on the system upon package removal without purging
Hi, Michael Biebl wrote: > To address this, we added code do dh_systemd, I assume you mean dh-systemd (the package) as there is no such command. > to mask the service on remove. So even if the package is only > removed, but not purged, be remaining sysv init script will not be > considered by systemd. This mask is removed on purge. Thanks for that hint. There's though no mentioning of masking in the dh_systemd_start(1) and dh_systemd_enable(1) man pages, there is no systemd2init man page, and /usr/share/doc/dh-systemd/ contains no further documentation either. After reading the source of /usr/share/perl5/Debian/Debhelper/Sequence/systemd.pm, I assume that dh $@ --with=systemd suffices. Will try that. Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ 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: ifup service delay (systemd 220)
Hello Alex, CC'ing the systemd packager list, if you don't mind. Keeping fullquote for that. Alex Mayer [2015-06-07 19:34 +]: > Hey Martin, > > i think two systemd 218-4 changes in /lib/systemd/system/ifup@.service are > the issue. > > > Type=oneshot > When no network available, it causes the service to take 75s. I have removed > this line temporarily. Right, there will be some DHCP timeouts until it fails. However, this rule should only be triggered via udev rules on hotplug events. Does that "take 75s" have any visible effect, i. e. do they stall other units that depend on it which shouldn't be stalled? > ExecStartPost=/sbin/ifquery --state %I > When network available, it lets ifup service fail. (without specified > Type=oneshot) The Type= shouldn't matter here, does it? Can you please be more detailled how it fails exactly, i. e. give me the output of systemctl status -l ifup@*.service and your /etc/network/interfaces? The unit that fails, does that belong to an actual network interface that gets brought up and is online, or something else? > For now i have removed both lines to restore systemd 215-18 like > functionality. > (At least the ifquery call may be removed as soon ifupdown bug #773539 is > fixed.) Right, I really don't like that workaround, but it doesn't seem right to let the unit succeed even if ifup'ing the interface actually fails. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
cannot extend network-manager unit file by using network-manager.service.d
Hi! This is what I did on Debian jessie... > sudo mkdir /etc/systemd/system/network-manager.service.d > sudo touch /etc/systemd/system/network-manager.service.d/x.conf > sudo systemctl daemon-reload Now, when running... > sudo service network-manager status Systemd keeps saying... > "Warning: Unit file changed on disk, 'systemctl daemon-reload' recommended." But I already did that at the beginning. This also persists after reboot. When I delete "/etc/systemd/system/network-manager.service.d/x.conf", the issue is gone. Can the network-manager unit file not be extended that way? What's the issue here? Works well for other unit files. Cheers, Patrick ___ 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: cannot extend network-manager unit file by using network-manager.service.d
Am 10.06.2015 um 15:50 schrieb Patrick Schleizer: > Hi! > > This is what I did on Debian jessie... > >> sudo mkdir /etc/systemd/system/network-manager.service.d >> sudo touch /etc/systemd/system/network-manager.service.d/x.conf >> sudo systemctl daemon-reload > > Now, when running... > >> sudo service network-manager status > > Systemd keeps saying... > >> "Warning: Unit file changed on disk, 'systemctl daemon-reload' > recommended." > > But I already did that at the beginning. This also persists after reboot. > > When I delete "/etc/systemd/system/network-manager.service.d/x.conf", > the issue is gone. > > Can the network-manager unit file not be extended that way? What's the > issue here? Works well for other unit files. /lib/systemd/system/network-manager.service is a symlink to /lib/systemd/system/NetworkManager.service Does it work if you use /etc/systemd/system/NetworkManager.service.d/x.conf -- 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#783509: systemd: /tmp purged on every reboot
Hello all, Michael and I just discussed this. Our current patches are shaky at best, and e. g. in the current 220-5 tmp.mount came back by default. I committed another bandaid for that, but it's a disaster waiting to happen. So we agreed on the following: - Stop shipping /lib/systemd/system/tmp.mount - Ship it in /usr/share/systemd/ instead - On upgrade: if tmp.mount is enabled, copy tmp.mount from /usr/share to /etc/ + Bonus (not required, but cleaner): update the enablement symlink accordingly - On new install: If RAMTMP==yes, copy tmp.mount from /usr/share and enable it - Update documentation about recommendation how to enable tmpfs /tmp: Add it to fstab, or do the copy/enable steps 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#788193: systemd: lost+found on /tmp-partition deleted during boot
Control: severity -1 important Am 09.06.2015 um 12:06 schrieb Ruediger Oberhage: >* What led up to the situation? > Booting Debian "Jessie". That dam*d "systemd" erases the "lost+found" > directory entry in "/tmp", which obviously is in its own partition. Looking at sysvinit's /lib/init/bootclean.sh, we have EXCEPT='! -name . ! ( -path ./lost+found -uid 0 ) ! ( -path ./quota.user -uid 0 ) ! ( -path ./aquota.user -uid 0 ) ! ( -path ./quota.group -uid 0 ) ! ( -path ./aquota.group -uid 0 ) ! ( -path ./.journal -uid 0 ) ! ( -path ./.clean -uid 0 ) ! ( -path './...security*' -uid 0 )' It looks reasonable to me, to mark the lost+found and quota bits as x in /usr/lib/tmpfiles/tmp.conf Might even be something which we should fix in jessie via pu. -- 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: Re: Bug#788193: systemd: lost+found on /tmp-partition deleted during boot
Processing control commands: > severity -1 important Bug #788193 [systemd] systemd: lost+found on /tmp-partition deleted during boot Severity set to 'important' from 'normal' -- 788193: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788193 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: Packaging issue: .service files are no conffiles (due to /lib) while init scripts are conffiles and hence remain longer on the system upon package removal without purging
Am 10.06.2015 um 13:19 schrieb Axel Beckert: > Michael Biebl wrote: >> To address this, we added code do dh_systemd, .. > After reading the source of > /usr/share/perl5/Debian/Debhelper/Sequence/systemd.pm, I assume that > > dh $@ --with=systemd > > suffices. > > Will try that. I just noticed, that /lib/systemd/system/screen-cleanup.service isn't actually a service file, but a symlink to /dev/null. This wasn't obvious to me from your first email. So technically, you already mask the sysv init script. I assume that is because you ship a tmpfiles snippet, /usr/lib/tmpfiles.d/screen-cleanup.conf (*) which implements the equivalent functionality. IIRC, dh_systemd_* only operates on real service files, so won't help you, as this is a very specific use case. So, option 2) might actually be the proper solution for your specific case after all. If you create that mask dynamically via postinst, this should be done in /etc though, I think. But let me first think about this more, before you go on implementing something. Michael (*) you seem to ship an empty /etc/tmpfiles.d directory for no apparent reason -- 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
Re: Packaging issue: .service files are no conffiles (due to /lib) while init scripts are conffiles and hence remain longer on the system upon package removal without purging
Hi, Michael Biebl wrote: > Am 10.06.2015 um 13:19 schrieb Axel Beckert: > > Michael Biebl wrote: > >> To address this, we added code do dh_systemd, > > .. > > > After reading the source of > > /usr/share/perl5/Debian/Debhelper/Sequence/systemd.pm, I assume that > > > > dh $@ --with=systemd > > > > suffices. > > > > Will try that. > > I just noticed, that /lib/systemd/system/screen-cleanup.service isn't > actually a service file, but a symlink to /dev/null. Yes. > This wasn't obvious to me from your first email. Yes, it seemed as if that was only a special case of a more general issue after reading the comments in LP#1462692. I didn't expect this to make such a difference. > So technically, you already mask the sysv init script. Ah, that's called "masking"? > I assume that is because you ship a tmpfiles snippet, > /usr/lib/tmpfiles.d/screen-cleanup.conf (*) which implements the > equivalent functionality. Yes. Because that init script does not much more than to clean up socket directories and set their permissions depending on the actual permissions of the screen binary. The latter wasn't possible in all details with systemd and was solved via an entry in debian/NEWS and debian/README.Debian. Background for this and some discussion are in https://bugs.debian.org/740301 > IIRC, dh_systemd_* only operates on real service files, so won't help > you, as this is a very specific use case. Ok. > So, option 2) might actually be the proper solution for your specific > case after all. If you create that mask dynamically via postinst, this > should be done in /etc though, I think. I would have expected /lib according to the argumentation in your previous mail. > But let me first think about this more, before you go on implementing > something. Ok. I'll revert the previously committed solution (1) and will likely do the next upload without a fix for LP#1462692. I want to make an upload of some packaging-only changes soon as there is a new upstream imminent. The fix for LP#1462692 was last thing I wanted to have in that upload, but it seems less trivial than expected. Anyway, thanks for caring! > (*) you seem to ship an empty /etc/tmpfiles.d directory for no apparent > reason See https://sources.debian.net/src/screen/4.2.1-3/debian/README.Debian/#L104 and the following lines for the reason. Was suggested by Josh and added in https://anonscm.debian.org/cgit/collab-maint/screen.git/commit/?id=f843000b Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ 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: Packaging issue: .service files are no conffiles (due to /lib) while init scripts are conffiles and hence remain longer on the system upon package removal without purging
Axel Beckert [2015-06-10 20:00 +0200]: > > So, option 2) might actually be the proper solution for your specific > > case after all. If you create that mask dynamically via postinst, this > > should be done in /etc though, I think. > > I would have expected /lib according to the argumentation in your previous > mail. I prefer /etc as well. This is *not* configuration which the admin is supposed to change. Thanks Axel! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ 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 787542
Processing commands for cont...@bugs.debian.org: > tags 787542 + pending Bug #787542 [libudev1-udeb] libudev1-udeb depends on missing libcap2 Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 787542: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787542 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: Packaging issue: .service files are no conffiles (due to /lib) while init scripts are conffiles and hence remain longer on the system upon package removal without purging
Am 10.06.2015 um 20:00 schrieb Axel Beckert: > Michael Biebl wrote: > Ok. I'll revert the previously committed solution (1) and will likely > do the next upload without a fix for LP#1462692. I want to make an > upload of some packaging-only changes soon as there is a new upstream > imminent. The fix for LP#1462692 was last thing I wanted to have in > that upload, but it seems less trivial than expected. > > Anyway, thanks for caring! Yeah, thanks as well for caring that your package works well under systemd! >> (*) you seem to ship an empty /etc/tmpfiles.d directory for no apparent >> reason > > See https://sources.debian.net/src/screen/4.2.1-3/debian/README.Debian/#L104 > and the following lines for the reason. Was suggested by Josh and added in > https://anonscm.debian.org/cgit/collab-maint/screen.git/commit/?id=f843000b Well, the /etc/tmpfiles.d directory is already shipped by systemd: $ dpkg -L systemd | grep /etc/tmpfiles /etc/tmpfiles.d And I think systemd is the correct package to own this directory. I think your point is, that the following command is supposed to work without having the user create the /etc/tmpfiles.d directory explicitly: echo 'd /var/run/screen 0755 root utmp' > /etc/tmpfiles.d/screen-cleanup.conf But if you are not using systemd (i.e., systemd is not installed), why would you care about creating an override tmpfiles snippet for screen? 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
/etc/tmpfiles.d in screen package (was: Re: Packaging issue: .service files are no conffiles ...)
Hi Michael, Michael Biebl wrote: > >> (*) you seem to ship an empty /etc/tmpfiles.d directory for no apparent > >> reason > > > > See https://sources.debian.net/src/screen/4.2.1-3/debian/README.Debian/#L104 > > and the following lines for the reason. Was suggested by Josh and added in > > https://anonscm.debian.org/cgit/collab-maint/screen.git/commit/?id=f843000b > > Well, the /etc/tmpfiles.d directory is already shipped by systemd: > $ dpkg -L systemd | grep /etc/tmpfiles > /etc/tmpfiles.d > > And I think systemd is the correct package to own this directory. Definitely. > I think your point is, that the following command is supposed to work > without having the user create the /etc/tmpfiles.d directory explicitly: > > echo 'd /var/run/screen 0755 root utmp' > > /etc/tmpfiles.d/screen-cleanup.conf Exactly. > But if you are not using systemd (i.e., systemd is not installed), why > would you care about creating an override tmpfiles snippet for screen? Indeed. I can't remember the details, but I vaguely remember that I didn't have a system running systemd for testing such things back then (only shortly afterwards), so I expect that I wasn't aware of systemd already shipping that directory. I'm totally fine with systemd shipping that directory, so I can drop it from screen. (I'd just would feel an urge to ship it again if systemd would no more ship that directory despite it still can be used.) Thanks for the explanations. Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ 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#788400: systemd-logind only fires suspend on lid close once even though it sees the event
Package: systemd Version: 220-5 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- Package-specific info: -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.1.0-rc7-hackers-of-the-world-unite (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages systemd depends on: ii adduser 3.113+nmu3 ii libacl1 2.2.52-2 ii libapparmor12.9.2-3 ii libaudit1 1:2.4.2-1 ii libblkid1 2.26.2-6 ii libc6 2.19-18 ii libcap2 1:2.24-8 ii libcap2-bin 1:2.24-8 ii libcryptsetup4 2:1.6.6-5 ii libgcrypt20 1.6.3-2 ii libkmod220-1 ii liblzma55.1.1alpha+20120614-2+b3 ii libmount1 2.26.2-6 ii libpam0g1.1.8-3.1 ii libselinux1 2.3-2 ii libsystemd0 220-5 ii mount 2.26.2-6 ii sysv-rc 2.88dsf-59.2 ii udev220-5 ii util-linux 2.26.2-6 Versions of packages systemd recommends: pn dbus pn libpam-systemd Versions of packages systemd suggests: pn systemd-ui -- no debconf information The following is my /etc/systemd/logind.conf: ``` [Login] #NAutoVTs=6 #ReserveVT=6 #KillUserProcesses=no #KillOnlyUsers= #KillExcludeUsers=root #InhibitDelayMaxSec=5 HandlePowerKey=suspend #HandleSuspendKey=suspend #HandleHibernateKey=hibernate HandleLidSwitch=suspend #HandleLidSwitchDocked=ignore #PowerKeyIgnoreInhibited=no #SuspendKeyIgnoreInhibited=no #HibernateKeyIgnoreInhibited=no #LidSwitchIgnoreInhibited=yes #HoldoffTimeoutSec=30s #IdleAction=ignore #IdleActionSec=30min #RuntimeDirectorySize=10% #RemoveIPC=yes ``` And the output of the systemd-logind.service, as you can see it fires `suspend` on the first lid close but never on any after the very first lid close, it is very odd, it clearly sees the event: ``` -- Logs begin at Wed 2015-06-10 16:49:40 PDT, end at Wed 2015-06-10 17:05:35 PDT. -- Jun 10 16:49:41 debian systemd[1]: Starting Login Service... Jun 10 16:49:41 debian systemd-logind[559]: New seat seat0. Jun 10 16:49:41 debian systemd-logind[559]: Watching system buttons on /dev/input/event4 (Power But Jun 10 16:49:41 debian systemd-logind[559]: Watching system buttons on /dev/input/event9 (Video Bus Jun 10 16:49:41 debian systemd[1]: Started Login Service. Jun 10 16:49:41 debian systemd-logind[559]: Watching system buttons on /dev/input/event2 (Power But Jun 10 16:49:41 debian systemd-logind[559]: Watching system buttons on /dev/input/event1 (Lid Switc Jun 10 16:49:41 debian systemd-logind[559]: Watching system buttons on /dev/input/event3 (Sleep But Jun 10 16:49:47 debian systemd-logind[559]: New session 1 of user jessie. Jun 10 16:52:18 debian systemd-logind[559]: Lid closed. Jun 10 16:52:18 debian systemd-logind[559]: Suspending... Jun 10 16:52:31 debian systemd-logind[559]: Lid opened. Jun 10 16:52:31 debian systemd-logind[559]: Operation finished. Jun 10 16:54:44 debian systemd-logind[559]: Lid closed. Jun 10 16:54:57 debian systemd-logind[559]: Lid opened. Jun 10 16:56:48 debian systemd-logind[559]: Lid closed. Jun 10 16:56:51 debian systemd-logind[559]: Lid opened. Jun 10 16:56:57 debian systemd-logind[559]: Lid closed. Jun 10 16:57:06 debian systemd-logind[559]: Lid opened. Jun 10 16:58:33 debian systemd-logind[559]: Lid closed. Jun 10 16:58:39 debian systemd-logind[559]: Lid opened. ``` [EXTENDED] /lib/systemd/system/systemd-timesyncd.service -> /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf [EXTENDED] /lib/systemd/system/rc-local.service -> /lib/systemd/system/rc-local.service.d/wait-online.conf 2 overridden configuration files found. # UNCONFIGURED FSTAB FOR BASE SYSTEM ___ 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: cannot extend network-manager unit file by using network-manager.service.d
Michael Biebl: > Am 10.06.2015 um 15:50 schrieb Patrick Schleizer: >> Hi! >> >> This is what I did on Debian jessie... >> >>> sudo mkdir /etc/systemd/system/network-manager.service.d >>> sudo touch /etc/systemd/system/network-manager.service.d/x.conf >>> sudo systemctl daemon-reload >> >> Now, when running... >> >>> sudo service network-manager status >> >> Systemd keeps saying... >> >>> "Warning: Unit file changed on disk, 'systemctl daemon-reload' >> recommended." >> >> But I already did that at the beginning. This also persists after reboot. >> >> When I delete "/etc/systemd/system/network-manager.service.d/x.conf", >> the issue is gone. >> >> Can the network-manager unit file not be extended that way? What's the >> issue here? Works well for other unit files. > > /lib/systemd/system/network-manager.service is a symlink to > /lib/systemd/system/NetworkManager.service > > Does it work if you use > > /etc/systemd/system/NetworkManager.service.d/x.conf Works for me. Thank you! Cheers, Patrick ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
could you look at http://bugs.debian.org/788380 part of it involves systemd-user
Hi Michael, Could you take a look at http://bugs.debian.org/788380 and see if it could be helped along ? -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8 ___ 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#788050: systemd-fsck : Check disks at each reboot
Hi A workaround is to boot in maintenance mode. The disks are then correctly checked and next normal boot is ok Regards Ludovic On Mon, 2015-06-08 at 10:26 +0200, Michael Biebl wrote: > Am 08.06.2015 um 08:01 schrieb Ludovic Lebègue: > > > For a few days now each time the computer boots it forces a file system > > check on two of my disks. > > > > Here is the relevant journalctl entry : > > > > Jun 08 07:48:19 leonardo kernel: input: PS/2 Generic Mouse > > as /devices/platform/i8042/serio1/input/input8 > > Jun 08 07:50:50 leonardo systemd-fsck[459]: fsck: Warning... fsck.ext4 > > for device /dev/sdb1 exited with signal 13. > > Jun 08 07:50:50 leonardo systemd-fsck[459]: fsck failed with error code > > 8. > > Jun 08 07:50:50 leonardo systemd-fsck[459]: Ignoring error. > > Jun 08 07:50:50 leonardo systemd[1]: Started File System Check > > on /dev/disk/by-uuid/553ea986-223e-4391-89be-c9da0c2fa197. > > Jun 08 07:50:50 leonardo systemd[1]: Mounting /home... > > Jun 08 07:50:50 leonardo kernel: EXT4-fs (sdb1): warning: maximal mount > > count reached, running e2fsck is recommended > > Jun 08 07:50:50 leonardo systemd[1]: Mounted /home. > > Jun 08 07:50:50 leonardo kernel: EXT4-fs (sdb1): mounted filesystem with > > ordered data mode. Opts: (null) > > Jun 08 07:51:32 leonardo systemd-fsck[460]: fsck: Warning... fsck.ext4 > > for device /dev/sdc1 exited with signal 13. > > Afaics, the underlying problem is, that fsck fails to fix the problems. > So it's rerun on each boot. > > What odd though, return code 13 is the sum of > > 1 Filesystem errors corrected > 4 Filesystem errors left uncorrected > 8 Operational error > > So, fsck at the same time says the errors were corrected, on the other > side it says they weren't. > Am I interpreting the return codes correctly? > > CCed the e2fsprogs maintainers for input. > signature.asc Description: This is a digitally signed message part ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
