Bug#774430: systemd: service makes as not reloadable
I'm experience the same, also with syslog-ng on a Debian/Jessie system (powerpc, upgraded from Debian/Wheezy not too long ago): # dpkg-query --status syslog-ng-core systemd | egrep ^Package\|^Version Package: syslog-ng-core Version: 3.5.6-2+b1 Package: systemd Version: 215-17 # systemctl -p CanReload show syslog-ng.service CanReload=no The /etc/logrotate.d/syslog-ng configuration asks to do invoke-rc.d syslog-ng reload which fails with the same error Tollef mentioned. I've put up some more details on http://paste.debian.net/172990/ A different machine has been running Debian/unstable (amd64) for a while but was not upgraded to systemd automatically and never encountered this bug here. After doing apt-get install systemd systemd-sysv and rebooting, I could not reproduce this issue here. Thanks, Christian. ___ 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: Proposal: enable stateless persistant network interface names
Martin Pitt [2015-05-08 7:59 +0200]: Details about [mac] --- [...] * It requires a writable /etc/udev/rules.d/ for persistantly storing the assignment. We don't want/have that with system-image (touch/snappy). Sorry, these are Ubuntu specific terms, forgot to edit. This meant to say: we don't have that with read-only or stateless root file systems, which become increasingly more popular. We do get bug reports in Debian as well about stuff that breaks r/o root; it's not much of an issue yet, so if you don't consider this a valid/sane use case just ignore this bit of the argument (the other reasons are still strong enough to change this anyway). 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: Proposal: enable stateless persistant network interface names
Hello Konstantin, Konstantin Khomoutov [2015-05-08 13:08 +0300]: Is it possible to provide a tool (a shell script?) that would print out the new would-be name of the interface provided by the user so that it would be possible to migrate remote systems only accessible via SSH? The closest thing to that would be something like this: $ sudo udevadm test /sys/class/net/wlan0 |grep ID_NET_NAME_ ID_NET_NAME_MAC=wlxa44e31848d2c ID_NET_NAME_PATH=wlp3s0 As I wrote the _MAC name isn't used by default (this has to be enabled explicitly, and it's a bit unwieldy); the default policy is to use the first existing variable in ID_NET_NAME_ONBOARD, ID_NET_NAME_SLOT, or ID_NET_NAME_PATH. Indeed it sounds useful to put that into a little shell script in /usr/share/doc/udev/ or so which the admin can run if she wants to migrate to the new names. I mean, a sysadmin would then be able to determine the new name of the network interface, reflect this change in the firewall setup and other relevant places, delete 70-persistent-net.rules and reboot the box (or may be perform some more involved encantation with calling ifdown / ip link name ... / ifup while in a screen/tmux session). It's not advisable to change network names at runtime. Well, you could stop all networking services and unload and reload the driver modules, but that sounds about as error prone as just rebooting :-) I don't know whether it's possible to change the name while the interface is up and in use. 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: Proposal: enable stateless persistant network interface names
On Fri, 8 May 2015 00:33:58 -0700 Josh Triplett j...@joshtriplett.org wrote: I propose to retire [mac], i. e. drop /lib/udev/rules.d/75-persistent-net-generator.rules and enable [ifnames] by default. [...] Having spent a non-trivial amount of time fighting persistent-net.rules on various systems, I'd very much welcome this change. To help migrate existing systems, I'd suggest including a NEWS.Debian file that explains the change, and recommends deleting /etc/udev/rules.d/70-persistent-net.rules on systems that don't depend on the exact names (for instance, systems that run NetworkManager rather than hard-coding network configuration in ifupdown's /etc/network/interfaces). Is it possible to provide a tool (a shell script?) that would print out the new would-be name of the interface provided by the user so that it would be possible to migrate remote systems only accessible via SSH? I mean, a sysadmin would then be able to determine the new name of the network interface, reflect this change in the firewall setup and other relevant places, delete 70-persistent-net.rules and reboot the box (or may be perform some more involved encantation with calling ifdown / ip link name ... / ifup while in a screen/tmux session). ___ 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: found 775458 215-17
Processing commands for cont...@bugs.debian.org: # problem also present in jessie found 775458 215-17 Bug #775458 [systemd] systemd: don't start services every few ms if condition fails Marked as found in versions systemd/215-17. thanks Stopping processing here. Please contact me if you need assistance. -- 775458: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775458 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: Proposal: enable stateless persistant network interface names
Martin Pitt mp...@debian.org writes: - [ifnames] For about two years (since 197) upstream's udev has a builtin persistant name generator which checks firmware/BIOS provided index numbers or slot names (like biosdevname), falls back to slot names (PCI numbers, Note that this makes the same bogus assumption about stable kernel names, just in a different subsystem. PCI buses can be and are hotplugged, similar to network devices. PCI bus numbering is no more guaranteed than say ethX network device numbering for any bus number 0. But if will appear to produce stable names most of the time, of course. Just like your builtin ethernet interface will be eth0 most of the time. Just a heads up for the first bug report... Bjørn ___ 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: [Pkg-clamav-devel] Bug#775112: systemd: repeatedly tries to start clamav
Processing control commands: found 775458 219-8 Bug #775458 [systemd] systemd: don't start services every few ms if condition fails Ignoring request to alter found versions of bug #775458 to the same values previously set -- 775458: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775458 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: [Pkg-clamav-devel] Bug#775112: systemd: repeatedly tries to start clamav
Processing control commands: found 775458 219-8 Bug #775458 [systemd] systemd: don't start services every few ms if condition fails Marked as found in versions systemd/219-8. -- 775112: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775112 775458: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775458 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#760923: halt no longer powers off the machine
Hi, just my opinion, of course, but please let me add: - changing finger memory is difficult, so I keep entering 'halt' instead of 'poweroff' occasionally - if one doesn't notice the error, this will waste electricity - if it happens on a notebook just before putting it into a bag, one may risk overheating - if it happens on a remote server which is configured to allow for wake-on-lan, one gets locked out, which may require manual intervention on the remote site. I guess I'm not the only one with these issues, so just changing the default to not power-off on halt may be a bad idea. Jan ___ 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#780235: man init brings up systemd(8) despite /sbin/init coming from sysvinit-core
Control: tags -1 - moreinfo unreproducible Control: reassign -1 man-db Am 08.04.2015 um 12:13 schrieb Michael Biebl: Control: tags -1 moreinfo unreproducible Am 10.03.2015 um 23:59 schrieb Samuel Bronson: Package: systemd Version: 215-12 Severity: important File: /usr/share/man/man1/systemd.1.gz Dear Maintainer, When I run man init, I expect to see the manpage corresponding to /sbin/init; since /sbin/init comes from sysvinit-core on my system, that would be init(8), but I get systemd(1) instead. I just tried to reproduce the problem in an up-to-date jessie chroot where sysvinit-core and systemd is installed. man init opens the sysvinit provided man page. Which version of man-db do you have installed? Can you still reproduce the issue? I did some further tests in a pristine, minimal jessie chroot (where systemd-sysv is installed by default): Installing sysvinit-core first, then man-db will give you /usr/share/man/man1/systemd.1.gz on man init. Installing man-db first, then sysvinit-core will give you /usr/share/man/man8/init.8.gz on man init. I think this points at an issue in man-db and some oddities regarding its index/cache file in /var/cache/man/index.db. Therefor reassigning accordingly. 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
Processed: Re: Bug#780235: man init brings up systemd(8) despite /sbin/init coming from sysvinit-core
Processing control commands: tags -1 - moreinfo unreproducible Bug #780235 [systemd] man init brings up systemd(8) despite /sbin/init coming from sysvinit-core Removed tag(s) unreproducible and moreinfo. reassign -1 man-db Bug #780235 [systemd] man init brings up systemd(8) despite /sbin/init coming from sysvinit-core Bug reassigned from package 'systemd' to 'man-db'. No longer marked as found in versions systemd/215-12. Ignoring request to alter fixed versions of bug #780235 to the same values previously set -- 780235: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780235 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: Proposal: enable stateless persistant network interface names
Hi, Karsten Merker: while this probably works resonably well for (semi-)fixed devices like onboard-NICs and PCI/PCIe cards, it results in a completely unsuitable behaviour with pluggable devices such as USB network adapters. Why? I can envision two likely scenarios for using a USB adapter. (a) you need to test something, so you plug in a handy USB adapter and configure it statically. So you're root and mucking about in /etc anyway, so also adding a one-liner to /etc/udev/rules.d/70-persistent-net.rules which names the adapter statically should not be a problem. (b) you're a client (e.g. you configure a new router), likely to use NetworkManager to just run a dhcp client on the adapter or configure a one-off RFC1918 address. So what if the adapter gets a different name next time? Most likely you need to configure a different device in a different '1918 subnet anyway. Or, if you use DHCP, there's no difference either way. In all other situations, quickly configuring a static address is no problem IMHO. Despite the problems of the MAC-based system that we use currently, the ifnames method appears way worse to me than what we have now. On a server, a missed rename due to interfaces showing up in exactly the wrong order makes the system unreachable. Frankly, I cannot imagine anything way worse than that. Not in this context. -- -- Matthias Urlichs 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: Proposal: enable stateless persistant network interface names
Just my 0.02$ against using the BIOS method. I have and Do see inconsistent bios vendor naming used from release to release of their Firmware updates. I have had to fix HP Propliants servers numerous time due to a firmware update changing the number and/or order of SATA ports, PCI and other things. So I for one dislike using bios provided info for any sort of userland namespace mapping method due to the above issues caused. -Joel On 8 May 2015 at 01:59, Martin Pitt mp...@debian.org wrote: Hello Debianists, Quick intro to the problem: The kernel generally detects network interfaces (eth0, wlan1, etc.) in an unpredictable and often unstable order. But in order to refer to a particular one in /etc/network/interfaces, firewall configs etc. you need to use a stable name. The general schema for this is to have an udev rule which does some matches to identify a particular interface, and assigns a NAME=foo to it. Interfaces with an explicit NAME= property get that name, and others just get a kernel driver default, usually ethN, wlanN, or sometimes others (some wifi drivers have their own naming schemas). Over the years several solutions have appeared: - [mac] For many many years our we have installed an udev rule /lib/udev/rules.d/75-persistent-net-generator.rules which on first boot creates a MAC address → current name mapping and writes /etc/udev/rules.d/70-persistent-net.rules. - [biosdevname] is a package originally written by Dell (IIRC), which reads port/index/slot names from the BIOS and sets them in /lib/udev/rules.d/71-biosdevname.rules. - [ifnames] For about two years (since 197) upstream's udev has a builtin persistant name generator which checks firmware/BIOS provided index numbers or slot names (like biosdevname), falls back to slot names (PCI numbers, etc., in the spirit of /dev/disks/by-path/), and then optionally (not done by default) falls back to MAC address (similar to [mac]). This happens in /lib/udev/rules.d/80-net-setup-link.rules. Note that these solutions can, and do get combined: The first rule which sets a name wins, i. e. currently [biosdevname] beats [mac] beats [ifnames]. Details about [mac] --- This is our current solution which applies to most hardware out there. It was an useful hack almost a decade ago, but it really shows its age: * It's subject to inherent race conditions (detecting a new device vs. renaming an existing one), which sometimes leads to devices being called renameX and breaking your boot. * It requires a writable /etc/udev/rules.d/ for persistantly storing the assignment. We don't want/have that with system-image (touch/snappy). * It's incompatible with how cloud images operate, as the physical (emulated from the VM host) devices can change between boots. Hence we maintain an ever-growing blacklist in 75-persistent-net-generator.rules which causes bugs and pain with each new cloud or virtualization provider. Recent examples: LP #1437375, #1367883, #1361272, #1317776, #1274348, #1099278. Support for [mac] got dropped in upstream udev two years ago, and since then we have maintained it on the Debian/Ubuntu side. Details about [biosdevname] --- This is a very good approach in principle, but unfortunately most desktop and laptop BIOSes out there don't actually set this kind of information, and of course none of the non-x86 machines do. I don't know how pervasive it is on dedicated server hardware. So this only actually helps for a small minority of cases, and currently falls back to [mac]. biosdevname isn't packaged in Debian, so it's not much of a concern in a Debian context. Some people might have installed the package from Dell or Ubuntu. Details about [ifnames] --- This is a generic solution which extends the [biosdevname] idea and thus applies to all practical cases and all architectures. It doesn't need any persistant state (i. e. dynamic /etc/udev/rules.d/) and thus applies nicely to snappy/touch, and also avoids the race condition. The main downside is that by nature the device names are not familiar to current admins yet. For BIOS provided names you get e. g. ens0, for PCI slot names enp1s1 (ethernet) or wlp3s0 (wlan). But that's a necessary price to pay (biosdevname names look similar). As this hasn't been discussed yet, Debian and Ubuntu disable this by default. You can opt into this by booting with net.ifnames=1 (which is a patch against upstream: there you disable it by booting with net.ifnames=0 or disabling 80-net-setup-link.rules). Proposal I propose to retire [mac], i. e. drop /lib/udev/rules.d/75-persistent-net-generator.rules and enable [ifnames] by default. This will provide the new stable interface names for all new installations, stop the different handling of server/client, work with
Re: Proposal: enable stateless persistant network interface names
On Fri, May 08, 2015 at 09:06:25PM +0200, Karsten Merker wrote: On Fri, May 08, 2015 at 10:50:30AM -0700, Josh Triplett wrote: Karsten Merker wrote: while this probably works resonably well for (semi-)fixed devices like onboard-NICs and PCI/PCIe cards, it results in a completely unsuitable behaviour with pluggable devices such as USB network adapters. When using ifnames, the interface name depends on the USB port into which the device is currently plugged and the interface name changes when one uses a USB hub or plugs the device into another host port. This would mean that a user would always have to plug his USB network device into the same port that was used during initial setup to keep it working, and one-off use of a USB hub would require changing the network configuration. Despite the problems of the MAC-based system that we use currently, the ifnames method appears way worse to me than what we have now. That would only be a problem if you're using ifupdown and its hardcoded network interface names. Other network software handles dynamic names. How is for example iptables supposed to handle changing interface names? Associate the rules with addresses, names, or other aspects of network topology, rather than specific interfaces. And for servers or routers (the common case for iptables usage), ifnames should provide quite stable names. IPtables rules often specify a specific incoming or outgoing interface, so the interface name must be known at the ruleset load time. This would mean that with the ifnames mechanism and its port-based interface naming, an iptables ruleset on a laptop with a USB network adapter would only work if the adapter is either always plugged into the same port or the user changes the ruleset every time he uses another USB port. On a laptop (or anywhere else), ideally you're using a higher-level tool than iptables. For instance, if you're trying to share connectivity from one network and NAT it to another, that's easily done with a few clicks these days. And it doesn't depend on which adapter Without this, you can't reliably use a system with *two* USB network devices, because they won't consistently come up with the same names. Or, for that matter, a system with a built-in network interface and a USB network interface. The current default MAC-based mechanism handles exactly this case very well on a number of systems for me (one built-in network interface and one or two USB network adapters). Every adapter always gets the same interface name, regardless of the bringup order. Answered in my other response, sorry. Yes, the MAC-based mechanism handles this too, but it has quite a few other issues. - 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
Re: Proposal: enable stateless persistant network interface names
Le vendredi 08 mai 2015 à 07:59 +0200, Martin Pitt a écrit : Proposal I propose to retire [mac], i. e. drop /lib/udev/rules.d/75-persistent-net-generator.rules and enable [ifnames] by default. Yes, yes, yes, please. Let’s get rid of that horrible thing. -- .''`. Josselin Mouette : :' : `. `' `- ___ 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: base-installer: NTP daemon should be installed on any system missing an RTC
On Sun, 03 May 2015 17:23:30 +0100 Ben Hutchings b...@decadent.org.uk wrote: Control: reassign -1 clock-setup Control: retitle -1 Missing support for systems without battery-backed RTC On Sun, 2015-05-03 at 17:40 +0200, Geert Stappers wrote: Debian installations on hardware with no (battery-backuped) RTC is likely an installation that hasn't network connection. What makes you think that? So please do not push (too hard) for you MUST allway known what time it is Make it possible to do installs on hardware without RTC and no access to a NTP server. Of course this should still be supported. Installing fake-hwclock https://packages.debian.org/stretch/fake-hwclock on the absence of the a RTC Avoiding filesystem checks when no RTC present would also be good. Simular as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767040 Good point. I'm retitling this because we now have three small related changes wanted in the installer: 1. Install/enable NTP client 2. Disable hwclock-save.service 3. Disable e2fsck time check I think these could all be done in clock-setup, so I'm reassigning to that. FWIW: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=experimentalid=929bece53261ddd2797d4f3518a05a88704c5b01 http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=experimentalid=5ea1b2bd1c57f9d3095252229c4ba1e50a7248d6 We enable timesyncd by default now and have dropped the hwclock-save.service in systemd for the systemd version targetted at stretch. Is there anything left which needs to be done? 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
Re: base-installer: NTP daemon should be installed on any system missing an RTC
Am 09.05.2015 um 03:32 schrieb Michael Biebl: On Sun, 03 May 2015 17:23:30 +0100 Ben Hutchings b...@decadent.org.uk 1. Install/enable NTP client 2. Disable hwclock-save.service See below for the changes in systemd 3. Disable e2fsck time check What exactly do you mean here? I think these could all be done in clock-setup, so I'm reassigning to that. FWIW: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=experimentalid=929bece53261ddd2797d4f3518a05a88704c5b01 http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=experimentalid=5ea1b2bd1c57f9d3095252229c4ba1e50a7248d6 We enable timesyncd by default now and have dropped the hwclock-save.service in systemd for the systemd version targetted at stretch. Is there anything left which needs to be done? Ben, just to clarify: Those changes you propose, are they meant for stretch or do you want to see them in a jessie point release? -- 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: base-installer: NTP daemon should be installed on any system missing an RTC
On Sat, 2015-05-09 at 03:38 +0200, Michael Biebl wrote: Am 09.05.2015 um 03:32 schrieb Michael Biebl: On Sun, 03 May 2015 17:23:30 +0100 Ben Hutchings b...@decadent.org.uk 1. Install/enable NTP client 2. Disable hwclock-save.service See below for the changes in systemd 3. Disable e2fsck time check What exactly do you mean here? e2fsck checks whether the current system time is earlier than the last mount time of the filesystem. If so, it may (depending on configuration) perform a full check. I think these could all be done in clock-setup, so I'm reassigning to that. FWIW: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=experimentalid=929bece53261ddd2797d4f3518a05a88704c5b01 http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=experimentalid=5ea1b2bd1c57f9d3095252229c4ba1e50a7248d6 We enable timesyncd by default now and have dropped the hwclock-save.service in systemd for the systemd version targetted at stretch. Is there anything left which needs to be done? Ben, just to clarify: Those changes you propose, are they meant for stretch or do you want to see them in a jessie point release? I don't know whether they are important enough to go into a point release. Ben. -- Ben Hutchings Theory and practice are closer in theory than in practice. - John Levine, moderator of comp.compilers 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
Re: base-installer: NTP daemon should be installed on any system missing an RTC
On Sat, 2015-05-09 at 03:32 +0200, Michael Biebl wrote: On Sun, 03 May 2015 17:23:30 +0100 Ben Hutchings b...@decadent.org.uk wrote: Control: reassign -1 clock-setup Control: retitle -1 Missing support for systems without battery-backed RTC On Sun, 2015-05-03 at 17:40 +0200, Geert Stappers wrote: Debian installations on hardware with no (battery-backuped) RTC is likely an installation that hasn't network connection. What makes you think that? So please do not push (too hard) for you MUST allway known what time it is Make it possible to do installs on hardware without RTC and no access to a NTP server. Of course this should still be supported. Installing fake-hwclock https://packages.debian.org/stretch/fake-hwclock on the absence of the a RTC Avoiding filesystem checks when no RTC present would also be good. Simular as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767040 Good point. I'm retitling this because we now have three small related changes wanted in the installer: 1. Install/enable NTP client 2. Disable hwclock-save.service 3. Disable e2fsck time check I think these could all be done in clock-setup, so I'm reassigning to that. FWIW: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=experimentalid=929bece53261ddd2797d4f3518a05a88704c5b01 So what happens if another ntp daemon is packaged, or they move executables into /usr/bin? http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=experimentalid=5ea1b2bd1c57f9d3095252229c4ba1e50a7248d6 We enable timesyncd by default now and have dropped the hwclock-save.service in systemd for the systemd version targetted at stretch. Is there anything left which needs to be done? Point 3 still needs to be fixed; at least on systems not using systemd-networkd the system clock will still be wrong when fsck runs. Ben. -- Ben Hutchings Theory and practice are closer in theory than in practice. - John Levine, moderator of comp.compilers 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
Bug#784604: systemd: can't remove systemd unless it is correctly running
On Fri, 8 May 2015 at 21:34 Michael Biebl bi...@debian.org wrote: I think the failure on uninstallation is just a red herring or just an aspect of a bigger issue, i.e. your systemd installation is not fully functional, most likely due to be run under OpenVZ (btw, it would have been helpful to mention that in the bug report). Which kernel version is that? Does it satisfy all requirements as listed in /usr/share/doc/systemd/README.gz? No. I think I already said this, didn't I? Please read the thread on debian-devel. I asked if I should file a bug report or not, and I was told Yes. https://lists.debian.org/debian-devel/2015/05/msg00013.html The problem isn't that systemd is broken, I know it is broken. The problem is that I know it is broken, but I can't remove it. Not everyone will be able to update the kernel, e.g. if using a 3rd party hosting provider, and don't won't to break their systems just because they forgot to disable installation of systemd. Like I said though, this doesn't affect me any more. After I upgrade me kernel I won't be able to reproduce the problem any more, and I won't be able to provide any more debugging information. ___ 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#784604: systemd: can't remove systemd unless it is correctly running
Am 08.05.2015 um 14:19 schrieb Brian May: On Fri, 8 May 2015 at 21:34 Michael Biebl bi...@debian.org wrote: I think the failure on uninstallation is just a red herring or just an aspect of a bigger issue, i.e. your systemd installation is not fully functional, most likely due to be run under OpenVZ (btw, it would have been helpful to mention that in the bug report). Which kernel version is that? Does it satisfy all requirements as listed in /usr/share/doc/systemd/README.gz? No. I think I already said this, didn't I? Please read the thread on debian-devel. I asked if I should file a bug report or not, and I was told Yes. https://lists.debian.org/debian-devel/2015/05/msg00013.html Sorry, I didn't read that debian-devel thread. The problem isn't that systemd is broken, I know it is broken. The problem is that I know it is broken, but I can't remove it. Not everyone will be able to update the kernel, e.g. if using a 3rd party hosting provider, and don't won't to break their systems just because they forgot to disable installation of systemd. Ok, this particular issue, as mentioned earlier, is probably solved by simply using || true in the dpkg trigger. I think it's safe to ignore errors from the dpkg trigger. -- 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#784604: systemd: can't remove systemd unless it is correctly running
Am 08.05.2015 um 05:22 schrieb Brian May:
On Thu, 7 May 2015 at 22:30 Michael Biebl bi...@debian.org wrote:
So, systemd.postinst seems to fail in the trigger
We do not call systemctl uncondionally here:
_systemctl() {
if [ -d /run/systemd/system ]; then
systemctl $@
fi
}
if [ $1 = triggered ]; then
_systemctl daemon-reload
exit 0
fi
So, this looks like you (wrongly) had a /run/systemd/system directory at
this point?
Yes, looks like it:
root@scrooge:/# ls -la /run/systemd/system/
total 0
drwxr-xr-x 2 root root 40 May 8 02:50
. drwxr-xr-x 6 root root
180 May 8 02:50 ..
That said, I'm still curious, why the systemctl call was made in the
first place. systemctl also complains with a D-Bus error.
Did you have a /var/run/dbus/system_bus_socket?
Doesn't look like I have that:
root@scrooge:/# ls -la /var/run/
total 4
drwxr-xr-x 4 root root 80 May 8 02:50 .
drwxr-xr-x 20 root root 4096 May 8 02:50 ..
drwxrwxrwt 2 root root 40 May 8 02:50 lock
drwxr-xr-x 6 root root 180 May 8 02:50 systemd
If that socket does not
exist, systemctl should fall back to use a private dbus socket which
doesn't require a run dbus system bus.
Was dbus installed at this point dbus.service and dbus.socket correctly
running?
dbus is installed, however it is not running. In fact I think systemd
hasn't actually started anything.
I think the failure on uninstallation is just a red herring or just an
aspect of a bigger issue, i.e. your systemd installation is not fully
functional, most likely due to be run under OpenVZ (btw, it would have
been helpful to mention that in the bug report).
Which kernel version is that? Does it satisfy all requirements as listed
in /usr/share/doc/systemd/README.gz?
I assume, you can reproduce the uninstallation failure on real iron or
in KVM when using the official Debian Jessie kernel?
--
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#784604: systemd: can't remove systemd unless it is correctly running
Am 08.05.2015 um 13:34 schrieb Michael Biebl: Which kernel version is that? Does it satisfy all requirements as listed in /usr/share/doc/systemd/README.gz? I assume, you can reproduce the uninstallation failure on real iron or can *not* reproduce... -- 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
