Closed #134.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/134#event-1851557811___
Rpm-maint mailing list
Rpm-maint@lists.rpm
It's just a plain old shell executing whatever was in the build script, it
doesn't know anything about rpm or blocks. Also any co-operative scheme is a
fail, what we'd like to catch is accidents.
As of commit 06953879d3e0b1e9a434979056d1225ab4646142 rpm kills any background
jobs left from build
Keep in mind that if rpmbuild itself used container features it'd heavily
overlap with tools like `mock` - and while recursive containerization does
work, it really requires both ends to be ready for it.
See also https://github.com/projectatomic/bubblewrap/issues/284
--
You are receiving this
Just two ideas:
1. What if there was something like begin, ensure, end block? I.e. I could
ensure that the executed process is really terminated, although the test suite
failed.
2. What if I could somehow register/execute some process in background using
some RPM framework? I.e. RPM would be aw
Well I'm not seriously suggesting dragging in systemd for a rare corner case
issue. OTOH we're not going to catch *all* children launched from a shell we
invoked without something more advanced and non-portable - all of those are
likely to look like serious overkill anyway.
We could of course
None of systemd-nspawn, systemd-run, mock or Koji or (for that matter) bash
have much to do with rpmbuild.
Expecting rpmbuild to solve complex issues involving runtime environment
cleanup is bad craziness.
You might consider -- say -- reporting an RFE to systemd or mock or koji or
bash to kill
If I remember correctly, I met this issue running rpmbuild inside mock, which
is actually using systemd-nspawn, which complained during the container
shutdown. Moreover, I think that systemd-run is not available inside mock, so I
am not convinced this is the right solution.
--
You are receivin
A simple way to achieve this would be running the build-scripts inside a
transient systemd unit. This is enough to make the reproducer to not hang
around:
```--- a/macros.in
+++ b/macros.in
@@ -792,9 +792,10 @@ package or when debugging this package.\
# Global defaults used for building sc
I tend to agree with @ignatenkobrain, no processes should be left around once
build completes.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/134#issuecomment-281286204_
@voxik try to compile package as I showed above. You run something in
background from RPM, you get RPMs, but process is still running which is IMO
not acceptable.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://gith
But honestly, I am no sure why/how this should be handled on RPM side ...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/134#issuecomment-275837496___
This is the use case:
http://pkgs.fedoraproject.org/cgit/rpms/rubygem-mongo.git/tree/rubygem-mongo.spec#n79
Please note it works just fine with rpm build or when using mock with
(--old-)chroot on the backend
--
You are receiving this because you are subscribed to this thread.
Reply to this ema
Imagine, we have some stupid program which forks and doesn't exit until we send
SIGTERM/SIGKILL, so build finishes, but process is still running. easy way to
reproduce is just run `./hang &` from `%check`.
I think @voxik has some real example in mongodb build while I have only dummy
one:
hang.
13 matches
Mail list logo
