Re: [systemd-devel] How to figure out what's causing systemd to start printing messages partway through boot?

2020-04-30 Thread McKay, Sean
Dug a little deeper and found the "(Enabling | Disabling) showing of status." debug log, which shows up exactly once in my journalctl output... but only on one type of system. I don't see it on the other (still trying to figure out if I could be hitting some sort of rate limiting). Nothing

Re: [systemd-devel] Requested transaction contradicts existing jobs: start is destructive

2020-04-30 Thread Kumar Kartikeya Dwivedi
On Thu, 30 Apr 2020 at 23:43, Uoti Urpala wrote: > > On Thu, 2020-04-30 at 22:18 +0530, Kumar Kartikeya Dwivedi wrote: > > waiting for the stop request initiated previously to finish). Even if > > you use fail as the job mode, the error you get back is "Transaction > > is destructive" or so, not

Re: [systemd-devel] Requested transaction contradicts existing jobs: start is destructive

2020-04-30 Thread Uoti Urpala
On Thu, 2020-04-30 at 22:18 +0530, Kumar Kartikeya Dwivedi wrote: > waiting for the stop request initiated previously to finish). Even if > you use fail as the job mode, the error you get back is "Transaction > is destructive" or so, not this. IIRC the patch he mentioned in his mail was one that

Re: [systemd-devel] Requested transaction contradicts existing jobs: start is destructive

2020-04-30 Thread Kumar Kartikeya Dwivedi
On Thu, 30 Apr 2020 at 16:56, Mark Bannister wrote: > > The documentation says that the default option for --job-mode is "replace", > i.e. > any conflicting pending job will be replaced, as necessary. > > How does it make sense for systemd to allow stop and start requests to > contradict anyway?

[systemd-devel] Requested transaction contradicts existing jobs: start is destructive

2020-04-30 Thread Mark Bannister
> On Mon, 2020-04-27 at 11:40 +0100, Mark Bannister wrote: > > One of the error messages I've been trying to explain is reported like this: > > 2020-04-22T00:45:47.047710-04:00 jupiter systemd[1]: Requested transaction > > contradicts existing jobs: Transaction for session-752473.scope/start is >

Re: [systemd-devel] systemd-hostnamed/hostnamectl and transient hostname change

2020-04-30 Thread Stef Walter
On 30.04.20 10:43, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Apr 27, 2020 at 12:00:36PM +0200, Thomas HUMMEL wrote: >> On 4/27/20 11:51 AM, Mantas Mikulėnas wrote: >> >> Hello, thanks for your answer. >> >>> On Mon, Apr 20, 2020 at 6:17 PM Thomas HUMMEL >>> mailto:thomas.hum...@pasteur.fr>> >>>

Re: [systemd-devel] systemd-hostnamed/hostnamectl and transient hostname change

2020-04-30 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Apr 27, 2020 at 12:00:36PM +0200, Thomas HUMMEL wrote: > On 4/27/20 11:51 AM, Mantas Mikulėnas wrote: > > Hello, thanks for your answer. > > >On Mon, Apr 20, 2020 at 6:17 PM Thomas HUMMEL > >mailto:thomas.hum...@pasteur.fr>> > >wrote: > > > >1. why does the transient hostname change

Re: [systemd-devel] systemctl restart changes permission.

2020-04-30 Thread Lennart Poettering
On Do, 30.04.20 09:35, Kaushal Shriyan (kaushalshri...@gmail.com) wrote: 65;6001;1c > Hi, > > I am running CentOS Linux release 7.8.2003 (Core) > with php72u-fpm-7.2.30-1.el7.ius.x86_64 version. I am facing the below > permission denied issue. I also did the below steps > #cd /run > #chown -Rc

Re: [systemd-devel] Crash and size problem with systemd-repart

2020-04-30 Thread Emmanuel Garette
Le 30/04/2020 à 09:56, Lennart Poettering a écrit : On So, 26.04.20 17:12, Emmanuel Garette (egare...@cadoles.com) wrote: Hi, I'm experimenting with the new tool systemd-repart and I think I have found a bug. Sorry for the late reply. The problem is in line "xsz =

Re: [systemd-devel] Crash and size problem with systemd-repart

2020-04-30 Thread Lennart Poettering
On So, 26.04.20 17:12, Emmanuel Garette (egare...@cadoles.com) wrote: > Hi, > > I'm experimenting with the new tool systemd-repart and I think I have found > a bug. Sorry for the late reply. > The problem is in line "xsz = partition_max_size(a->after);" > > xsz is the max size of "a->after"