Description of problem: # systemctl status plymouth-start â plymouth-start.service - Show Plymouth Boot Screen Loaded: loaded (/usr/lib/systemd/system/plymouth-start.service; static; vendor preset: enabled) Active: failed (Result: signal) since Mon 2016-01-18 06:47:47 CST; 30min ago Process: 585 ExecStartPost=/bin/plymouth show-splash (code=exited, status=2) Process: 575 ExecStart=/sbin/plymouthd --mode=boot --pid-file=/run/plymouth/pid --attach-to-session (code=exited, status=0/SUCCESS) Main PID: 584 (code=killed, signal=SEGV) Jan 18 06:47:45 tb.home.test systemd[1]: Starting Show Plymouth Boot Screen... systemd[1]: plymouth-start.service: Main process exited, code=killed, status=11/SEGV plymouth[585]: error: unexpectedly disconnected from boot status daemon Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Reproducible: Steps to Reproduce:
Assigning to all packagers collectively, because plymouth has no maintainer.
CC: (none) => marja11Assignee: bugsquad => pkg-bugs
(In reply to Bit Twister from comment #0) > Description of problem: You seem to be missing something meanful here, apart from the status output. What is the actual problem that you encountered, when doing what? Did you see plymout splash when booting, did it hang/block the boot, or anything else happened? Steps to reproduce are also not present ... > # systemctl status plymouth-start
CC: (none) => doktor5000
(In reply to Florian Hubold from comment #2) > something meanful here err, something _meaningful_ here :)
(In reply to Florian Hubold from comment #2) > (In reply to Bit Twister from comment #0) > > Description of problem: > > You seem to be missing something meanful here, apart from the status output. No, I thought an app attempting to address memory outside of its control was meaning enough. My guess is it needs some other service running before it can start working. > What is the actual problem that you encountered, Problem is application fails to run the first time. > when doing what? Booting. > Did you see plymout splash when booting, No, I want to see what might be failing rather than having to debug what is wrong with something not running. Reverent snippet from from /var/log/dmesg kernel: Command line: BOOT_IMAGE=mga6_64_netinstall root=LABEL=hh noresume noiswmd audit=0 vga=794 > did it hang/block the boot, Yes, until plymouth-start timed out and was restarted. > or anything else happened? Rest of the services completed while plymouth-start was timing out. > Steps to reproduce are also not present ... Sorry, always doing a "reboot", after clearing the logs for the next boot. /local/bin/new_boot_logs code snippet follows: !/bin/bash _cmd=reboot <snipped bunch of files being removed, others being nulled with cp /dev/null and stopping services which can hang shutdown for several minutes. > :( echo "clearing journal log" _log_dir=/var/log/journal/$(cat /etc/machine-id) if [ -e $_log_dir ] ; then echo "Wiping journal logs" systemctl kill --signal=SIGUSR1 systemd-journald.service systemctl kill --signal=SIGUSR2 systemd-journald.service sleep 2 /bin/rm -f $_log_dir/user-*.journal /bin/rm -f $_log_dir/*@* fi echo " Running $_cmd" sleep 1 $_cmd exit
Hardware: i586 => x86_64Summary: mga6: plymouth-start.service: Main process exited, code=killed, status=11/SEGV => 6_s1: plymouth-start.service: Main process exited, code=killed, status=11/SEGVSource RPM: plymouth-0.9.2-3.mga6.src.rpm => plymouth-0.9.2-4.mga6.src.rpm
(In reply to Florian Hubold from comment #2) > (In reply to Bit Twister from comment #0) > Did you > see plymout splash when booting, did it hang/block the boot, or anything > else happened? Removal of splash argument causes the failure. No, idea why it is able to restart the second time.
Summary: 6_s1: plymouth-start.service: Main process exited, code=killed, status=11/SEGV => 6_s1: plymouth-start.service fails to run first time with "splash" argument removed
no longer seeing fail message in journal.
Status: NEW => RESOLVEDResolution: (none) => FIXED
You removed the splash boot argument, and then wonder why bootsplash fails to run? Totally makes sense ...
(In reply to Florian Hubold from comment #7) > You removed the splash boot argument, and then wonder why bootsplash fails > to run? > Totally makes sense ... Seems you are a bit behind in your reading since this was resolved about two months ago. Had you bothered to read the bug title and Description the bug is about the Plymouth.Start service failing because of the removed argument. The problem is that the service should not have failed the first time.