2017-03-08 20:32 GMT+01:00 Michael Biebl :
>>> And due to the use of
>>> RefuseManualStart=yes
>>> RefuseManualStop=yes
>>
>> This has been cargo culted & could also be changed,
>> but I prefer the first option (the .target that controls everything).
>
> I don't see a good reason why the individual
Control: tags -1 + patch
Am 08.03.2017 um 14:48 schrieb Felipe Sateler:
> https://github.com/systemd/systemd/commit/47fffb35
>
> Unfortunately, that does not apply cleanly to 215, so some backporting
> will be needed.
Cherry-picking
https://github.com/systemd/systemd/commit/96fb8242
https://git
Am 08.03.2017 um 20:12 schrieb Alexandre Detiste:
> Hi,
>
>> systemd-cron *does* stop cron.target in prerm in recent versions, but
>> stopping cron.target *does not* stop cron-update.path.
>>
>> Contrary to the other units, cron-update.path is not marked as
>> PartOf=cron.target.
>
> So could it
Hi,
> systemd-cron *does* stop cron.target in prerm in recent versions, but
> stopping cron.target *does not* stop cron-update.path.
>
> Contrary to the other units, cron-update.path is not marked as
> PartOf=cron.target.
So could it be enough to just add this "PartOf=cron.target"
to cron-updat
I removed the fixed tag.
systemd-cron *does* stop cron.target in prerm in recent versions, but
stopping cron.target *does not* stop cron-update.path.
Contrary to the other units, cron-update.path is not marked as
PartOf=cron.target.
And due to the use of
RefuseManualStart=yes
RefuseManualStop=ye
Am 08.03.2017 um 15:30 schrieb Alexandre Detiste:
> Hi,
>
> The path activation is pulled-in like the rest by cron.target,
> so stopping cron.target is enough to also stop cron-update.path .
No it is not. Starting cron.target starts cron-update.path, but stopping
cron.target does not stop cron-up
Hi,
The path activation is pulled-in like the rest by cron.target,
so stopping cron.target is enough to also stop cron-update.path .
Back then, this commit was enough to solve this bug in v1.5.2-1;
well maybe having a more recent debhelper/dh_systemd available helped too.
https://anonscm.debian.
Control: clone -1 -2
Control: retitle -2 systemd-cron: stop cron-update.path before removal
Control: reassign -2 systemd-cron 1.3.1+ds1-2
Control: found -1 215-1
Control: fixed -1 232-1
On Tue, Mar 7, 2017 at 11:32 PM, Andreas Bombe wrote:
> On Tue, Mar 07, 2017 at 10:05:38AM +0100, Michael Bieb
On Tue, Mar 07, 2017 at 10:05:38AM +0100, Michael Biebl wrote:
> Andreas, can you confirm that stopping the cron-update.path unit prior
> to the removal avoids the crash? You will have to edit
> /lib/systemd/system/cron-update.path to remove
> RefuseManualStart=true
> RefuseManualStop=true
I did
Am 07.03.2017 um 11:21 schrieb Alexandre Detiste:
> Hi,
>
> Isn't this a duplicate of #813879 / #776859 ?
>
>
> I remember code is there but needs a sponsor:
>
> https://anonscm.debian.org/cgit/collab-maint/systemd-cron.git/commit/?h=jessie&id=06f38df6e42bf60f44ce4ceb8cf752c819ea92da
>
Disabl
Hi,
Isn't this a duplicate of #813879 / #776859 ?
I remember code is there but needs a sponsor:
https://anonscm.debian.org/cgit/collab-maint/systemd-cron.git/commit/?h=jessie&id=06f38df6e42bf60f44ce4ceb8cf752c819ea92da
Alexandre Detiste
> The changes I proposed to systemd-cron (i.e. stopping
Am 07.03.2017 um 10:05 schrieb Michael Biebl:
> My suggestion would be, that systemd-cron stops cron-update.path in
> prerm on "remove", to disable path triggering at a point where the
> package is in an inconsistent state.
>
> This seems to me to be the least invasive fix for jessie by avoiding
Am 06.03.2017 um 22:53 schrieb Andreas Bombe:
> Package: systemd
> Version: 215-17+deb8u6
> Severity: important
>
> I have a rented virtual server running jessie. The virtualization
> environment is OpenVZ according to hostnamectl.
>
> There are problems with the jessie version of systemd-cron (c
For the record, my bug appears to have been reported before as #776863.
I have generated a more complete backtrace from the same core:
[New LWP 2615]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `ini
It was pointed out to me that there should be core dumps and indeed
there were from both instances of it happening to me. Here is one
backtrace, the other looks identical:
#0 0x7fc21779775b in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
#1 0x7fc217bed4a8 in crash.lto_
15 matches
Mail list logo
