Hi,
I just found root cause for this sevice not to start. It was simple parent folder permission issue. In this case it was /opt/apps/sdc which was set to root:root. I changed it to sdc:sdc and it allowed actual sdc_home inside /opt/SP/apps to start service without
error code. Can you suggest why it was not the issue for one server where other 5 servers i had to change ownership. Systemd version was same in all 6 servers. Only difference i found was switched-root .Just fyi i am very beginner in for rhel 7 and so systemd
troubleshoot.
Thanks,
Krunal.
From: systemd-devel <systemd-devel-bounces@xxxxxxxxxxxxxxxxxxxxx> on behalf of Lennart Poettering <lennart@xxxxxxxxxxxxxx>
Sent: Monday, October 8, 2018 1:38:37 PM
To: Jérémy Rosen
Cc: systemd-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: Default on failure dependencies
Sent: Monday, October 8, 2018 1:38:37 PM
To: Jérémy Rosen
Cc: systemd-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: Default on failure dependencies
On Mo, 08.10.18 09:58, Jérémy Rosen (jeremy.rosen@xxxxxxxx) wrote:
>
> > This all makes me wonder whether a different approach to all of this
> > wouldn't be better: maybe we should just consider this a logging
> > problem: let's make sure we log a recognizable log message (i.e. a
> > structured journal message with a well-defined MESSAGE_ID=) whenever a
> > service fails. With that in place it should be relatively easy to
> > write a system service that can run during regular system uptime and
> > can look in the journal for all failures, including getting live
> > notifications when something happens. Moreover, this resolves the
> > problems during early and late boot: the "cursor" logic of the journal
> > allows such a service to know exactly which failures it already
> > processed and which ones are still left, and it can process all
> > failures that took place while it was not running.
> >
> > Does that make sense?
>
> Could this be generalized to "a structured message whenever a unit changes
> state" or would that be too verbose ?
We have that already but only in debug logging mode (systemd-analyze
log-level debug). It's a bit too much noise to turn on by default otherwise...
Lennart
--
Lennart Poettering, Red Hat
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
> > This all makes me wonder whether a different approach to all of this
> > wouldn't be better: maybe we should just consider this a logging
> > problem: let's make sure we log a recognizable log message (i.e. a
> > structured journal message with a well-defined MESSAGE_ID=) whenever a
> > service fails. With that in place it should be relatively easy to
> > write a system service that can run during regular system uptime and
> > can look in the journal for all failures, including getting live
> > notifications when something happens. Moreover, this resolves the
> > problems during early and late boot: the "cursor" logic of the journal
> > allows such a service to know exactly which failures it already
> > processed and which ones are still left, and it can process all
> > failures that took place while it was not running.
> >
> > Does that make sense?
>
> Could this be generalized to "a structured message whenever a unit changes
> state" or would that be too verbose ?
We have that already but only in debug logging mode (systemd-analyze
log-level debug). It's a bit too much noise to turn on by default otherwise...
Lennart
--
Lennart Poettering, Red Hat
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
