I just installed OpenSuse 12.3. System start is very slow and if I hit ESC to hide boot splash, I can see that the system hangs at “Started Recreate Volatile Files and Directories”. I found that it might be caused by some failing services so I tried systemctl list-units --all |grep error and this is what I got:
$ systemctl list-units --all |grep error
acpid.service error inactive dead acpid.service
amavis.service error inactive dead amavis.service
apparmor.service error inactive dead apparmor.service
auditd.service error inactive dead auditd.service
basic.service error inactive dead basic.service
cyrus.service error inactive dead cyrus.service
exim.service error inactive dead exim.service
firstboot.service error inactive dead firstboot.service
ldap.service error inactive dead ldap.service
multipath.service error inactive dead multipath.service
network-remotefs.service error inactive dead network-remotefs.service
nfsserver.service error inactive dead nfsserver.service
openslp.service error inactive dead openslp.service
resmgr.service error inactive dead resmgr.service
scsidev.service error inactive dead scsidev.service
sendmail.service error inactive dead sendmail.service
syslog-ng.service error inactive dead syslog-ng.service
syslogd.service error inactive dead syslogd.service
winbind.service error inactive dead winbind.service
ypserv.service error inactive dead ypserv.service
local_fs.target error inactive dead local_fs.target
That’s kind of a lot of errors and it seems to me that many of those failing services are completely different and independent. Any thoughts? Should I try to eliminate one error by one or is it possible that there’s a common cause for all of this?
My pc is quite exotic. It’s Asus Zenbook UX32VD and it has two ssd’s in RAID 0.
wolfi@amiga:~> systemctl list-units --all |grep error
acpid.service error inactive dead acpid.service
amavis.service error inactive dead amavis.service
cyrus.service error inactive dead cyrus.service
exim.service error inactive dead exim.service
firstboot.service error inactive dead firstboot.service
ldap.service error inactive dead ldap.service
multipath.service error inactive dead multipath.service
network-remotefs.service error inactive dead network-remotefs.service
openslp.service error inactive dead openslp.service
resmgr.service error inactive dead resmgr.service
scsidev.service error inactive dead scsidev.service
sendmail.service error inactive dead sendmail.service
setserial.service error inactive dead setserial.service
syslog-ng.service error inactive dead syslog-ng.service
syslogd.service error inactive dead syslogd.service
ypserv.service error inactive dead ypserv.service
local_fs.target error inactive dead local_fs.target
And when I do “systemctl status acpid.service” then f.e. I get:
wolfi@amiga:~> systemctl status acpid.service
acpid.service
Loaded: error (Reason: No such file or directory)
Active: inactive (dead)
wolfi@amiga:~>
That’s because it isn’t even installed…
I guess it’s the same for at least most of yours.
But if you do have acpid installed you should remove it. It can conflict with systemd and cause issues like hangs f.e.
And you can run “systemd-analyze blame” to find out which service takes how long to start (you need to install the package “systemd-analyze” first). Maybe you find your culprit there.
All those services do not exist (load status is “error”). They appear in configuration because of dependencies (e.g. some other service wants to be After: acpid.service, so systemd creates placeholder for acpid.service. If service definition is seen later, it becomes instantiated; otherwise it remains in state “load error”).
and, did you self-test the install media by booting from it (do NOT
run it from inside MS-Windows) and selecting “Check Installation
Media” like you see here http://tinyurl.com/b856ekd
any error in either test is too many! and the path to a smile
begins by getting the install media 100% right.
Those “errors” are there because those service files do not exist, because those packages are not installed.
Nothing to do with a bad installation media.
Just try to call “systemctl list-units --all |grep error” yourself on your system…
On 2013-06-28 14:36, tobice wrote:
>
> I just installed OpenSuse 12.3. System start is very slow and if I hit
> ESC to hide boot splash, I can see that the system hangs at “Started
> Recreate Volatile Files and Directories”. I found that it might be
> caused by some failing services so I tried systemctl list-units --all
> |grep error and this is what I got:
Use instead:
systemctl --failed --no-pager
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
> wait! is this a byproduct of a not-yet-ready-for-prime-time systemd?
No, I think that systemd includes service files for services not yet
installed, so that they are there when you do install them. It would be
better if those packages included the systemd services themselves, so
that they get installed at the proper time.
Just an educated guess
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
I used systemd-analyze and found out that I had a wrong entry in fstab and the start up process was waiting for non existent swap partition. I fixed that entry and the system now starts only few seconds (thanks to ssd). Apparently it’s a quite common problem and it’s caused during the process of creating partitions. When installing OpenSuse, I canceled the proposed disk setup and configured partitions myself. However the installer didn’t reflect these changes I made about the swap partition and put wrong entry into fstab.
Anyway, those failing services were completely irrelevant in this case and from your posts it seems that it is completely ok that they are marked with error. I find it kind of confusing… but whatever… important is that it works.
Well, my theory is about the same as arvidjaar stated.
Those services are references by other services (in the “After” section f.e.) and systemd creates placeholders for them internally.
No, that’s not the case.
systemd doesn’t include those service files, they are included in their respective program’s package.
And because they are not installed, those services can’t be started of course.
On 2013-06-29 00:06, tobice wrote:
>
> Thanks guys for a lot of answers.
>
> I used systemd-analyze and found out that I had a wrong entry in fstab
> and the start up process was waiting for non existent swap partition. I
> fixed that entry and the system now starts only few seconds (thanks to
> ssd). Apparently it’s a quite common problem and it’s caused during the
> process of creating partitions. When installing OpenSuse, I canceled the
> proposed disk setup and configured partitions myself. However the
> installer didn’t reflect these changes I made about the swap partition
> and put wrong entry into fstab.
That’s worth a bug report, if you can provide the logs.
> Anyway, those failing services were completely irrelevant in this case
> and from your posts it seems that it is completely ok that they are
> marked with error.
If you issue “systemctl --failed” you will see that they are not.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
Well I’m not entirely sure that THIS happened. It’s only my assumption based on other posts found around that described pretty much the same situation and possible original cause. Unfortunately there are no logs about what I did during the installation.
But it doesn’t help me, does it? When I was trying to find out what was wrong I came across the solution described above (i. e. that wrong swap entry might be the problem). But then I run “systemctl”, I saw many “errors” and I said to myself “wow…something is seriously wrong with my computer, that must be the problem why my laptop is booting so slowly”. And I completely forgot about the swap thing. Unfortunately. I came to it back when systemd-analyze told me that md.service was the one that was slowing down the entire start up process. At that point I realized that the swap really might be the problem. So yes… it’s kind of confusing, but it’s not a big deal
>> That’s worth a bug report, if you can provide the logs.
>>
>>
>
> Well I’m not entirely sure that THIS happened. It’s only my assumption
> based on other posts found around that described pretty much the same
> situation and possible original cause. Unfortunately there are no logs
> about what I did during the installation.
Machine logs, not human logs. They are files in your system. They are
there, unless rotated.
> robin_listas;2568193 Wrote:
>> On 2013-06-29 00:06, tobice wrote:
>>
>>> Anyway, those failing services were completely irrelevant in this case
>>> and from your posts it seems that it is completely ok that they are
>>> marked with error.
>>
>> If you issue “systemctl --failed” you will see that they are not.
> But it doesn’t help me, does it? When I was trying to find out what
> was wrong I came across the solution described above (i. e. that wrong
> swap entry might be the problem). But then I run “systemctl”, I saw many
> “errors” and I said to myself “wow…something is seriously wrong with
> my computer, that must be the problem why my laptop is booting so
> slowly”. And I completely forgot about the swap thing. Unfortunately. I
> came to it back when systemd-analyze told me that md.service was the one
> that was slowing down the entire start up process. At that point I
> realized that the swap really might be the problem. So yes… it’s kind
> of confusing, but it’s not a big deal
What I mean is that the above command says what services are really
failed, whereas the “grep error” you did, does not.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
Machine logs, not human logs. They are files in your system. They are
there, unless rotated.
I meant machine logs. But it took me about 30 minutes to configure partitions the way I wanted it so there would have to be a log of every step I took and canceled during the setup. If there really is, tell me where and I will file a bug.
On 2013-06-29 12:16, tobice wrote:
>
>> Machine logs, not human logs. They are files in your system. They are
>> there, unless rotated.
>>
>>
>
> I meant machine logs. But it took me about 30 minutes to configure
> partitions the way I wanted it so there would have to be a log of every
> step I took and canceled during the setup. If there really is, tell me
> where and I will file a bug.
As I’m not a yast dev, I don’t know if all that is logged or not. If
they are, the files are in /var/log/YaST2/. There is a script,
“save_y2logs” which collects needed logs into a tgz archive. There is a
set of rotated logs, named “y2log-X.gz”, the X going from 1 to 9;
looking at the dates, you know if the installation is covered or not.
But as you say, I don’t know if cancellations are logged or not. They
might…
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
On 2013-06-29 13:36, tobice wrote:
>
> I filed the bug: https://bugzilla.novell.com/show_bug.cgi?id=827481
>
> I found the log. It doesn’t contain the changes, but it clearly does
> show that the fstab entry is wrong. I hope it will help.
Good
Lets hope they find the culprit and improve the system.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
One more thing for anyone with the same problem: the wrong entry is put not only to the fstab file, but also to the grub resume partition which prevents you from using hibernate.
> One more thing for anyone with the same problem: the wrong entry is put
> not only to the fstab file, but also to the grub resume partition which
> prevents you from using hibernate.
When I was trying to find out what was wrong I came across the solution described above (i. e. that wrong swap entry might be the problem). But then I run “systemctl”, I saw many “errors” and I said to myself “wow…something is seriously wrong with my computer, that must be the problem why my laptop is booting so slowly”. And I completely forgot about the swap thing. Unfortunately. I came to it back when systemd-analyze told me that md.service was the one that was slowing down the entire start up process. At that point I realized that the swap really might be the problem. So yes… it’s kind of confusing, but it’s not a big deal