Bug#771172: systemd-sysv-generator does not generate
Package: systemd Version: 215-6 Severity: critical Justification: breaks unrelated software Dear Maintainer, I am not providing the additional information that reportbug wants to provide because if I do, the mail will be rejected as spam by bogus filters. Dear Maintainer, somehow, after the last upgrade (which included dbus, console-setup, libpolkit-backend, schroot) I was unable to start postfix. While upgrading I had this message: insserv: FATAL: service dnsmasq is missed in the runlevels 2 3 4 5 to use service postfix that caused the entire upgrade to fail. I didn't know what was the problem, the LSB headers seemed fine, so I removed /etc/init.d/postfix and /etc/init.d/dnsmasq and proceeded with the upgrade. After the upgrade I put the scripts in their original position. Then, I noticed that postfix was not running and could not be started ● postfix.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) which is when I learnt about the existance of systemd-sysv-generator (which lacks a man page and doesn't support a -h switch) After some investigation I found out that these generated files belong in /run/systemd/generator.late/, for systemd to be able to run the service. There was no such file there for postfix, so I ran the tool, which generated files in /tmp, and then moved the postfix.service inside the correct location, to be able to start it. I have no clue of what happened with insserv and why it was failing in the first place, and I guess that systemd refusing to start my service was due to my removing and then adding the script. However, I might want to copy a script in /etc/init.d at anytime and I would expect systemd to be able to run it, without first having to run some undocumented tool. Please let me know if you need more information about the problem. Best -- Package-specific info: -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.17.2d (SMP w/4 CPU cores; PREEMPT) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd depends on: ii acl 2.2.52-2 ii adduser 3.113+nmu3 ii initscripts 2.88dsf-58 ii libacl1 2.2.52-2 ii libaudit1 1:2.4-1 ii libblkid1 2.25.2-3 ii libc6 2.19-13 ii libcap2 1:2.24-6 ii libcap2-bin 1:2.24-6 ii libcryptsetup4 2:1.6.6-3 ii libgcrypt20 1.6.2-4 ii libkmod218-3 ii liblzma55.1.1alpha+20120614-2+b1 ii libpam0g1.1.8-3.1 ii libselinux1 2.3-2 ii libsystemd0 215-6 ii mount 2.25.2-3 ii sysv-rc 2.88dsf-58 ii udev215-6 ii util-linux 2.25.2-3 Versions of packages systemd recommends: ii dbus1.8.12-1 ii libpam-systemd 215-6 Versions of packages systemd suggests: pn systemd-ui none -- Configuration Files: /etc/systemd/logind.conf changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771172: systemd-sysv-generator does not generate
Am 27.11.2014 um 12:01 schrieb Salvo Tomaselli: Package: systemd Version: 215-6 Severity: critical Justification: breaks unrelated software Dear Maintainer, I am not providing the additional information that reportbug wants to provide because if I do, the mail will be rejected as spam by bogus filters. Dear Maintainer, somehow, after the last upgrade (which included dbus, console-setup, libpolkit-backend, schroot) I was unable to start postfix. Was postfix part of the upgrade? While upgrading I had this message: insserv: FATAL: service dnsmasq is missed in the runlevels 2 3 4 5 to use service postfix that caused the entire upgrade to fail. That sounds like a bug in insserv. I didn't know what was the problem, the LSB headers seemed fine, so I removed /etc/init.d/postfix and /etc/init.d/dnsmasq and proceeded with the upgrade. After the upgrade I put the scripts in their original position. Then, I noticed that postfix was not running and could not be started ● postfix.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) If you remove an init script and systemctl daemon-reload is run, systemd will re-run the sysv-generator and the generated unit is removed as well. Since during the upgrade systemctl daemon-reload has been triggered most likely by e.g. dbus's maintainerscript, it's expected that the generated unit for postfix is removed and the error message you get above. It doesn't necessarily mean that the postfix process is stopped, unless the postfix package was part of the upgrade and the service stopped in prerm. So what could have happened is: - apt-get (dist-)upgrade - postfix's prerm is run and the postfix process is stopped - you get the insserv error during the upgrade - you fix the insserv error by removing the postfix init script - you resume the upgrade, systemctl daemon-reload is triggered by another like dbus and therefore the generated postfix.service unit is removed which is when I learnt about the existance of systemd-sysv-generator (which lacks a man page and doesn't support a -h switch) After some investigation I found out that these generated files belong in /run/systemd/generator.late/, for systemd to be able to run the service. There was no such file there for postfix, so I ran the tool, which generated files in /tmp, and then moved the postfix.service inside the correct location, to be able to start it. Running systemctl daemon-reload is sufficient to run the generator. You don't need to run it by hand and copying the files around. I have no clue of what happened with insserv and why it was failing in the first place, and I guess that systemd refusing to start my service was due to my removing and then adding the script. However, I might want to copy a script in /etc/init.d at anytime and I would expect systemd to be able to run it, without first having to run some undocumented tool. If you install an init script, you'll need to run systemctl daemon-reload for systemd to pick it up. The package maintainer scripts do that automatically. That's also true for native services fwiw. Please let me know if you need more information about the problem. The failing insserv process looks like a genuine bug to me, and I suggest you file a corresponsing bug against that package. The behaviour of systemd is by design and an explicit choice by upstream. What you want afai is systemd monitoring /etc/init.d and /(lib|etc)/systemd/system, e.g. via inotify, and automatically reloading when there are changes in those directories. I'll mark this bug as a feature request (i.e. wishlist) but also wontfix, since upstream has rejected such a change in behaviour and we won't deviate in such a fundamental way downstream. If you want to see this changed, I think it's best if you engage with upstream directly. 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
Bug#771172: systemd-sysv-generator does not generate
In data giovedì 27 novembre 2014 15:40:01, Michael Biebl ha scritto: Am 27.11.2014 um 12:01 schrieb Salvo Tomaselli: Package: systemd Version: 215-6 Severity: critical Justification: breaks unrelated software Dear Maintainer, I am not providing the additional information that reportbug wants to provide because if I do, the mail will be rejected as spam by bogus filters. Dear Maintainer, somehow, after the last upgrade (which included dbus, console-setup, libpolkit-backend, schroot) I was unable to start postfix. Was postfix part of the upgrade? No it wasn't. If you remove an init script and systemctl daemon-reload is run, systemd will re-run the sysv-generator and the generated unit is removed as well. Since during the upgrade systemctl daemon-reload has been triggered most likely by e.g. dbus's maintainerscript, it's expected that the generated unit for postfix is removed and the error message you get above. It doesn't necessarily mean that the postfix process is stopped, unless the postfix package was part of the upgrade and the service stopped in prerm. It was not, possibly I had stopped it after I got the error, to try to convince dpkg to finish configuring. I did a few attempts before managing to convince it. Running systemctl daemon-reload is sufficient to run the generator. You don't need to run it by hand and copying the files around. I wasn't even aware there was such a thing. rantI thought systemd was supposed to be a drop in replacement. Which clearly is not./rant So I am rather clueless on systemd's usage. If you install an init script, you'll need to run systemctl daemon-reload for systemd to pick it up. The package maintainer scripts do that automatically. This breaks compatibility tho, and also, i tried to run the script manually as a script (without service) but it was redirecting to systemd and insisted in failing to start. Perhaps the magic wrapper or whatever can be improved to detect this case? It doesn't make much sense when I try to run a shell script and I get a failure because apparently the file I'm running doesn't exist. (except if you know how systemd works, then I guess it makes sense). That's also true for native services fwiw. Oh this explains why I had to reboot after creating a .service file! Thanks for your help :-) -- 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/ signature.asc Description: This is a digitally signed message part.
Bug#771172: systemd-sysv-generator does not generate
On Thu, Nov 27, 2014 at 09:06:11PM +0100, Salvo Tomaselli wrote: Running systemctl daemon-reload is sufficient to run the generator. You don't need to run it by hand and copying the files around. I wasn't even aware there was such a thing. rantI thought systemd was supposed to be a drop in replacement. Which clearly is not./rant So I am rather clueless on systemd's usage. drop in replacement is an impossible task. The logic on which systemd is built is too different to sysvinit. The goal is provide a way to support well-behaved existing init scripts, possibly with small modifications. I added a man page upstream for systemd-sysv-generator (http://cgit.freedesktop.org/systemd/systemd/commit/?id=f509443af5). It's not very exhaustive, but provides the basic pointers. People who care about sysv compat will hopefully extend it at some point. That's also true for native services fwiw. Oh this explains why I had to reboot after creating a .service file! Actually you don't have to. Even running systemctl daemon-reload is usually not necessary, since 'systemctl start xxx.service' will load the unit if didn't previously know about it. HTH, Zbyszek -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
