Re: Service fails to start with no log messages

[Reindl Harald <h.reindl@xxxxxxxxxxxxx>]

Am 07.01.20 um 03:17 schrieb Jeffrey Walton:
> On Mon, Jan 6, 2020 at 9:13 PM Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote:
>>
>> Am 07.01.20 um 03:06 schrieb Jeffrey Walton:
>>> On Mon, Jan 6, 2020 at 9:03 PM Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote:
>>>>
>>>> Am 07.01.20 um 02:57 schrieb Jeffrey Walton:
>>>>> On Mon, Jan 6, 2020 at 8:56 PM Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote:
>>>>>>
>>>>>> Am 07.01.20 um 02:42 schrieb Jeffrey Walton:
>>>>>>> On Mon, Jan 6, 2020 at 8:34 PM Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote:
>>>>>>>>
>>>>>>>> Am 07.01.20 um 02:28 schrieb Jeffrey Walton:
>>>>>>>>> I'm trying to determine my service fails to start. I copied the
>>>>>>>>> service to the systemd unit directory, and then enabled and started
>>>>>>>>> the service. Upon reboot the service is not started automatically.
>>>>>>>>>
>>>>>>>>> Here are the logs:
>>>>>>>>
>>>>>>>> Jan 06 20:25:33 raspberrypi systemd[1]: graphical.target: Job
>>>>>>>> callboot-ui.service/start deleted to break ordering cycle starting
>>>>>>>> with graphical.target/start
>>>>>>>>
>>>>>>>> you have some conflicting After/Before ordering which is impossible to
>>>>>>>> solve automatically, it's that simple
>>>>>>>
>>>>>>> But there is no ordering problem. callboot-ui.service is not related
>>>>>>> to callboot-monitor.service. callboot-ui.service is a Qt program and
>>>>>>> front-end to the LCD screen. callboot-monitor.service is a command
>>>>>>> line program that waits for reads of the modem.
>>>>>>>
>>>>>>> The only thing they have in common is they use the same database.
>>>>>>
>>>>>> frankly "to break ordering cycle starting with graphical.target" and
>>>>>> your "callboot-monitor.service" has "Wants=graphical.target" and you
>>>>>> call that "not releated"?
>>>>>>
>>>>>> Especially the "Wants" is problematic and noramlly not needed for
>>>>>> enabled services, normally your only use After/NBefore unless there is a
>>>>>> compelling resason for Wants/Requires and with growing useless
>>>>>> dependencies you add to your units problems gow
>>>>>>
>>>>>> perfomance wise because you break parallel starts for no benefit and
>>>>>> because of such unsolveable cycles if you obviously don't understand
>>>>>> what you define becaus eotherwise you won't have After/Before/wants in
>>>>>> combinations which are impossible
>>>>>>
>>>>>> and to your other post "5 seconds after all systems services have
>>>>>> actually started" is something which simply don#t exist and can't exist
>>>>>> at all
>>>>>>
>>>>>> fix your orderings and your problems are gone
>>>>>
>>>>> To fix my ordering problem I need Systemd to stop lying about when the
>>>>> network is ready.
>>>>
>>>> it don't - you most likely did something wrong by the ordering afetr
>>>> networking and you even don't tell how your networking is configured
>>>> (network.service, networkmanager, systemd-networkd...)
>>>>
>>>> in other words: instead fix your network-ordering properly you touch
>>>> other random stuff in weird ways and it's annyoing that one needs to ask
>>>> for each and every bit given your initial posting was a completly joke
>>>> with no single information and the whole topic "Service fails to start
>>>> with no log messages" is wrong at all
>>>
>>> I think that was a very good summary of the problem.
>>>
>>> I want my monitor service to start (it is the most important one), but
>>> there are absolutely no traces of it.
>>
>> there are, it's orderred after graphical.traget which has a dependency cycle
> 
> There are absolutely 0 entires about my monitor service:
> 
>     $ journalctl -e | grep -i callboot | grep monitor
>     $
> 
> If you are claiming I fiddled with graphical.target and when/how it
> starts, I did not.

god damned! you did with "After=graphical.target" and
"Wants=graphical.target" as well as nobody knows what "usb.target" does
given it's not default

than your "callboot-ui.service" has a dependency cycle in context of
"ordering cycle starting with graphical.target" which needs to be solved

and you pretend you did not fiddle with grahpical target

frankly - remove all your Wants where you likely only think you know
what you are doing and also all your After/Before and start to define
them from scratch

while you are at it verify that you ordering after network was done
correctly because what you did because of it was the start of all the
other issues nad all your problemls magically disappear

what people all the time are doing wrong is not understaning how network
ordering works and given that you are not willing to provide
informations by common sense unasked im am done with you

the problem is not systemd, not journald and not systemd-timers, it's in
front of the screen
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel