[systemd-devel] How to implement fsck progress report with systemd and plymouth?

[fykcee1 at gmail.com]

2011/4/25 Lennart Poettering <lennart at poettering.net>:
> On Fri, 22.04.11 15:04, fykcee1 at gmail.com (fykcee1 at gmail.com) wrote:
>
>> Hi all,
>>
>> plymouth in Ubuntu 10.04 supports fsck progress report, and also
>> provides a chance for user to cancel running fsck. How to implement
>> this feature with systemd and plymouth?
>
> It's actually a really hard problem. For example, what do you do when
> you have multiple disks which are fsck'ed in parallel or serial? You'd
> then have to integrate their individual progress bars somehow.
It seems ubuntu's implementation uses limited 'progress bars'. I guess
any more fsck progress reports will no be displayed.

>
>> I did some investigation, found:
>> 1. ubuntu patches on_update() of plymouth/src/main.c, it will filter
>> out status message from fsck, if message starts with "fsck:".
>> 2. ubuntu provides a plymouth theme -- ubuntu-logo, which is of type
>> script, and has some fsck related stuff.
>>
>> I guess we need:
>> 1. Support "detailed status report" in plymouth, e.g. colon separated
>> fields.
>> 2. Hook fsck detailed message to each theme in plymouth ?
>> 3. Emit fsck message to plymouth in systemd-fsck.
>> 4. How to support user-cancellable fsck?
>
>> Any idea?
>
> Here's what I'd suggest: We already have systemd-fsck, which we could
> beef up slightly to pass progress data to a tiny AF_UNIX socket
> activated service (let's call it fsckd) which integrates the data from
> multiple instances of systemd-fsck and sends it off to plymouth. And if
> a cancel request is received from plymouth it would send off SIGINT to
> the the systemd-fsck instances which it got data from.
>
> This could be done in a relative easy and elegant way by having
> systemd-fsck just pass the socket it created as channel to fsckd as -C
> fd to to fsck. That way only fsckd would have to parse the progress data
> from fsck, and it would talk directly to fsck which would allow fsckd to
> figure out the fsck PID via SCM_CREDENTIALS, so that fsckd would know
> what to kill.
Good idea. Thanks.



-- 
Regards,
- cee1