| 1 |
The proper way to figure out what failed to start and why is to use systemctl |
| 2 |
|
| 3 |
# list of running services |
| 4 |
systemctl |
| 5 |
|
| 6 |
# status of particular service |
| 7 |
systemctl status name-of-service |
| 8 |
|
| 9 |
Now if your concern is the service loading order, then you're really |
| 10 |
talking about problems in your unit files, i.e., there's a dependency |
| 11 |
or sequencing instruction that wasn't included. Unlike sysvinit, you |
| 12 |
don't need a reboot to determine or solve load order problems. |
| 13 |
|
| 14 |
On Tue, Jul 30, 2013 at 2:29 AM, <covici@××××××××××.com> wrote: |
| 15 |
> Canek Peláez Valdés <caneko@×××××.com> wrote: |
| 16 |
> |
| 17 |
>> On Mon, Jul 29, 2013 at 6:11 AM, <covici@××××××××××.com> wrote: |
| 18 |
>> > I want to -- at least in initial testing -- have systemd not try to do |
| 19 |
>> > things in parallell -- one at a time is very nice -- I even have openrc |
| 20 |
>> > configured that way. Any way to do this? |
| 21 |
>> |
| 22 |
>> No if you don't use --confirm-spawn AFAIK; the whole parallel start |
| 23 |
>> thingy is deeply integrated in systemd's design. And, why would you |
| 24 |
>> want to start things sequentially? |
| 25 |
> |
| 26 |
> Because its much easier to figure out things -- particularly if |
| 27 |
> something has gone wrong -- and I don't boot that often, so I don't |
| 28 |
> really care if it takes a bit longer -- its certainly a lot less than |
| 29 |
> that other OS. |
| 30 |
> |
| 31 |
> And thanks for your response. |
| 32 |
> |
| 33 |
> |
| 34 |
> |
| 35 |
> -- |
| 36 |
> Your life is like a penny. You're going to lose it. The question is: |
| 37 |
> How do |
| 38 |
> you spend it? |
| 39 |
> |
| 40 |
> John Covici |
| 41 |
> covici@××××××××××.com |
| 42 |
> |
| 43 |
|
| 44 |
|
| 45 |
|
| 46 |
-- |
| 47 |
This email is: [ ] actionable [ ] fyi [ ] social |
| 48 |
Response needed: [ ] yes [ ] up to you [ ] no |
| 49 |
Time-sensitive: [ ] immediate [ ] soon [ ] none |
Archives