ntp postun script is bogus: # urpme ntp removing ntp-4.2.6p5-7.mga3.x86_64 Usage: service -[Rfshv] SERVICE ARGUMENTS -f|--full-restart: Do a fullrestart of the service. -R|--full-restart-all: Do a fullrestart of all running services. -s|--status-all: Print a status of all services. --ignore-dependencies: Do not start required systemd services --skip-redirect: Do not redirect to systemd -d|--debug: Launch with debug. -h|--help: This help. error reading information on service ntpd: No such file or directory removing package ntp-4.2.6p5-7.mga3.x86_64
Keywords: (none) => Junior_jobCC: (none) => guillomovitch, luigiwalserTarget Milestone: --- => Mageia 3
Actually it's preun, not postun. %preun %_preun_service ntpd Why is this error happening?
CC: (none) => mageia
It's happening with many packages - I mentioned it to Col a couple of days ago on IRC:- Sep 25 23:03:30 <barjac> coling: Any ideas on this during uninstall of packages with units (not only munin): removing munin-node-2.0.6-1.mga3.noarch - error reading information on service munin-node: No such file or directory ? Sep 25 23:04:11 <coling> barjac, of the top of my head, no. Sep 25 23:04:27 <coling> I'm guessing it comes from the daemon-reload file trigger tho'. Sep 25 23:05:01 <barjac> coling: OK - it happens with zoneminder too
CC: (none) => zen25000
Well the error comes from the /usr/share/rpm-helper/del-service script, and it needs to determine whether it's running under systemd or sysvinit. It sounds like the recent systemd update has that detection broken and it thinks it's running under sysvinit and is trying to stop a SysV service with the service command rather than stopping a systemd service with systemctl. The detection code is: /bin/mountpoint -q /sys/fs/cgroup/systemd Which gives a 0 exit status for me on Mageia 2.
Keywords: Junior_job => (none)Source RPM: ntp-4.2.6p5-7.mga3 => systemd
Summary: ntp postun script is bogus: => systemd detection in rpm-helper no longer works
Assignee: bugsquad => mageia
*** Bug 7616 has been marked as a duplicate of this bug. ***
*** Bug 7615 has been marked as a duplicate of this bug. ***
*** Bug 7614 has been marked as a duplicate of this bug. ***
*** Bug 7613 has been marked as a duplicate of this bug. ***
*** Bug 7612 has been marked as a duplicate of this bug. ***
*** Bug 7610 has been marked as a duplicate of this bug. ***
Well, it should be easy fix then as sysvinit is dead for mga3 anyway :)
CC: (none) => sander.lepik
I'm confused, /bin/mountpoint -q /sys/fs/cgroup/systemd is still giving me a 0 exit status on Cauldron... So I'm confused as to why this has broken :s
Well yes then, that is quite strange indeed. Perhaps it doesn't matter, because as Sander said the sysvinit logic could be stripped out of the rpm-helper scripts and then it wouldn't matter anyway.
Well, I'm not 100% sure it can be stripped out as we will still support upgrading via urpmi from mga2. As mga2 support sysvinit boots, we can't guarantee that the urpmi upgrade is happening under a systemd boot and thus when services are being restarted during the upgrade, we should really handle sysvinit restarts gracefully. So I'm not sure we should tidy it up too much right now.
Oh that's right, and as we've discussed in the past, there's no guarantee rpm-helper gets upgraded early in the upgrade procedure, so the old script needs to work.
Even if rpm-helper is upgraded early, it still has to work on the current sysvinit boot even although systemd will be used after the post-upgrade reboot into mga3.
OK, so back to the actual bug, I can add an if/else that hides the "error reading information on service ntpd: No such file or directory" error, but it probably won't actually work here as the mountpoint check is failing. Is the error happening in a chrooted environment with /sys not bind mounted to the host? If so then I can understand it as it won't be a mountpoint and thus systemd won't be detected. Thierry can you confirm you are seeing this on current cauldron booted normally? I can only reproduce the "error reading information..." part of it. Also David can you confirm that the mountpoint check is failing for you on cauldron boot? It should return 0 just as in mga2.
I'm not running Cauldron. I was just looking at the script, and that's the only logical explanation for what's happening.
I was in a chrooted cauldron
In real system: [baz@jackodesktop ~]$ /bin/mountpoint -q /sys/fs/cgroup/systemd [baz@jackodesktop ~]$ echo $? 0
In a second clean Cauldron minimal LXDE system :- [root@localhost baz]# urpme zoneminder removing zoneminder-1.25.0-17.mga3.tainted.x86_64 error reading information on service zoneminder: No such file or directory removing package zoneminder-1.25.0-17.mga3.tainted.x86_64 [root@localhost baz]# /bin/mountpoint -q /sys/fs/cgroup/systemd [root@localhost baz]# echo $? 0
OK, the error Barry is talking about is a different one than what Thierry was. I'm guessing Barry's error is coming from this line of the script: [ -n "$srv" ] && /sbin/chkconfig --del $srv Barry, try *not* uninstalling something but just running chkconfig --del on its service instead and see if you get the same error.
Actually I'm not guessing, that error message definitely comes from chkconfig. It should have been doing this all along, as even chkconfig on Mageia 1 gives that error when you --del a non-existent service (at least one that doesn't have a SysV init script). It could be that this error is just starting to show up as we drop SysV init scripts from packages. The code in del-service when it calls chkconfig should probably have 2> /dev/null
It's definitely showing up due to removing sysvinit scripts. This part of the error can be fixed with a simple if/else statement as I mentioned above in comment 16. So this should be an easy one to solve. The problems resulting from the chrooted setup are not new and will have been there since pre-mga2 days, so probably not something new to worry about. I'll push an updated rpm-helper tomorrow.
I don't know about an if/else, at least if you're referring to those two lines where it removes service links with both systemctl and chkconfig unconditionally. The script can be called with a service name and a list of additional systemd units to remove, and if the main service itself is a SysV init script, it's appropriate to run both commands. I suppose you could add some code to detect if that's actually the case.
Well just to explain the logic, the reason to unconditionally run both commands is actually to deal with the case where both a native systemd and sysvinit script exists. My original logic was that when we remove a package, if we only ran the systemctl command, it would only take care of the native units if one was found (it will automatically call chkconfig if a native unit does not exist), thus potentially leaving the sysvinit script enabled and thus some hanging symlinks left behind. So that's why I called both commands. I've now modified it slightly to only call chkconfig if the rc.d script exists which should avoid the problem. The chroot issue is still there, but then as it's not new I'm not sure what we should do here... I'd rather a switch to assuming systemd and some way to detect sysvinit in use, but I can't think of a way to do this easily...
After a year, does this bug still exist in current Cauldron or Mageia 3?
CC: (none) => tarakbumba
No replies. Then i close this bug report. If you believe that it occurs in current Cauldron or Mageia 3 with updates installed then do not hesitate to reopen.
Status: NEW => RESOLVEDResolution: (none) => OLD