On Thu, 2013-05-16 at 12:20 -0600, Chris Murphy wrote:
> These are the remaining items that I don't understand why they run at all, on every boot.
>
>
> There have been no crashes, so ext4 doesn't need fsck on every boot:
>
> 4.051s systemd-fsck-root.service
> 515ms systemd-fsck@dev-disk-by\x2duuid-09c66d01\x2d8126\x2d39c2\x2db7b8\x2d25f14cbd35af.service
>
>
>
> and no oops, so this seems unnecessary:
>
> 1.092s abrt-uefioops.service
So abrt-uefioops.service always runs (it doesn't have any systemd
conditionals), and it does this:
# Wait for abrtd to start. Give it at least 1 second to initialize.
i=10
while ! pidof abrtd >/dev/null; do
if test $((i--)) = 0; then
exit 1
fi
sleep 1
done
sleep 1
cd /sys/fs/pstore 2>/dev/null || exit 0
abrt-merge-uefioops -o * | abrt-dump-oops -D
if test $? = 0; then
abrt-merge-uefioops -d *
fi
Now, the ordering there looks wonky to me. It waits for abrtd to start
and *then* checks if /sys/fs/pstore even exists. So I see various
possible improvements here.
1. Why is it waiting for abrtd to 'initialize' at all? That seems like a
messy hack. If abrtd.service is returning early, surely that should be
fixed, rather than putting ugly sleep loops in things that depend on it.
2. Move the 'wait for abrtd' stuff to under the 'cd /sys/fs/pstore
2>/dev/null || exit 0' line. Then at least if /sys/fs/pstore doesn't
exist at all, we can exit without waiting for a second.
3. Make the whole service conditional on there being anything
in /sys/fs/pstore at all. In practice, just doing this would resolve the
problems and make 1 and 2 unnecessary (though still possibly desirable).
To do that, just add this to the abrt-uefioops.service file:
ConditionDirectoryNotEmpty=/sys/fs/pstore
> How do I determine what component to file a bug against? I guess I
> have to find the package that caused these .service files to be
> installed?
Yes. 'rpm -qf /lib/systemd/system/foo.service'.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
