Am 19.08.2011 18:46, schrieb Lennart Poettering: > On Fri, 19.08.11 18:00, Reindl Harald (h.reindl@xxxxxxxxxxxxx) wrote: > > Heya, > >> * no feedback of systemctl and wrong from /sbin/service-wrapper > Like most Unix commands systemctl will not output anything in case of > success, only on failure. See cp, ln, mv, rm for similar behaviour. if you are replacing /sbin/service which gave feedback over all the years you have to give feedback too and not make the same crap like apple and NO it does also not give feedback if service fails >> * systemctl does not stop .socket if you stop .service > And it shouldn't. There's an item on the todo list to add a warning if > the user stops a service unit but leaves the socket unit running. it should if you say it shouldn't you have a hughe design-mistake in the whole software - if i say "service stop anythign" i mean stop and not that any dumkb software fires it up if you can give a warning you can also stop the socket this is what the user expects and if your software-design is not able to act logically it is broken >> * useless auto-completion for systemctl > Hmm? Bug#? "service restart htt" you can type TAb the whole day and will get no auto-completion if the service is running - shos me you are not really using your own software and i did not think a bugreport for such basics is needed >> * no progress while fs-check on boot > The way I'd like to see this fixed is that fsck's -C switch can > optionally take a path like /dev/console to output its progress > bar. Then again, ideally the progress information would be passed on to > Plymouth instead of the console. In both cases systemd should probably > not be involved. sorry to say but: it does nobody interest what you like a fs-check on a 4 TB disk without any feedback is unnaccpetable because inak KVM-Session you see not disk-LED's and do not hear the drive - so with your behavior in the worst case somebody forces a hard restart while fsck is running >> D* no green Ok / red FAILED at boot time, only a desert of text > Not really true. > > First of all, we will output "Starting ..." and "Started ..." messages > as the boot proceeds if you remvoe "quiet" from the kernel cmdline. If a > service fails, we will even say that and highlight it in red. What we > won't do however is mark success in green, in order to keep visual > distraction minimal. i first disable the dumb quite-option on every install i recommend you take a look at a F14 boot and yours it is a hughe differene having a red colored FAILED or your text-desert with no difference and the output of the service-description instead a short name is simply a design-mistake > On top of that, at any time you can type in "systemctl" and you'll get > colorful output of what services successfully started and which ones > didn't. This is a substantial improvement over classic SysV where the > boot time output scrolled away quickly and only screen-scraping could > help to get a bit of an idea what actually started properly and what > didn't. yes it is a improvent to get htis after the boot but if you restart a server you nromally watch the boot and have no reason to login as long you see nothing red - this was broken by the usability-pifall how systemd boots
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel