informations about boot sequence (Re: F15 - mysql start problem)

[Michał Piotrowski]

2011/5/9 Tomasz Torcz <tomek at pipebreaker.pl>:
> On Mon, May 09, 2011 at 11:26:50AM -0400, Tom Lane wrote:
>> =?ISO-8859-2?Q?Micha=B3_Piotrowski?= <mkkp4x4 at gmail.com> writes:
>> > Ok, I know what is happening. I looked at the init script and I
>> > realized that it doesn't have any LSB header info about boot process
>> > order.
>>
>> No, it's assuming that the chkconfig numbering takes care of that.
>> Are you saying that systemd no longer honors the chkconfig ordering?
>> That doesn't leave me with a warm feeling about how much testing the
>> systemd stuff has gotten, because there is all kinds of stuff that's
>> liable to fall over without that.
>
>  Systemd ignores chkconfig ordering for native services.  And orders
> by requirements.  So it is crucial to have proper Requires= and After=
> in unit files.

Unfortunately I did not have time to create native services for PgSQL
and MySQL, so I need to use old sysvscripts - therefore, I noticed
this problem. OTOH these are the last two sysvinit scripts that I use
- so I probably did not noticed more problems with other things :)

I wonder how many of these problems arises in large systems after upgrade to F15

>
>> > I also looked at other services and here are some of them that
>> > needs fixing:
>> > - memcached - (I created systemd service for it) - I can provide a
>> > patch for classic init script
>> > - smb - as above
>> > - nmb - as above
>> > - mysql - I can provide a patch for classic init scrip
>> > - postgresql - as above
>>
>> Yes, mysql and postgresql are both certainly broken by this.  Please
>> send the info, I'll take care of those two.
>
>  We have hackish NetworkManager-wait-online.service which can be requested
> in such cases.  But it really shouldn't be used.  Services should have
> proper requirements set, deal with dynamic network nature.  And ideally
> by socket activable, so we don't have to deal with such issues.
>
> --
> Tomasz Torcz               RIP is irrevelant. Spoofing is futile.
> xmpp: zdzichubg at chrome.pl     Your routes will be aggreggated. -- Alex Yuriev
>
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>



-- 
Best regards,
Michal

http://eventhorizon.pl/