On 01/12/2012 04:44 AM, Dr. Michael J. Chudobiak wrote:
explanation of what's so much better about systemd I'd be glad to follow
it and learn, but it's not urgent enough for me to go hunting and
weeding out all of the blind leads.
http://0pointer.de/blog/projects/why.html summarizes it pretty well.
I found the old style of unit scripts to be a pain in the ass. I'm not
sure why people think it was so great.
I think it's more to do with its heritage. It's been around for a very
long time and is well understood. Systemd has a very steep learning
curve, is harder to debug because of the said lack of understanding and
trying to get your head around service dependencies is a real challenge.
It also has some peculiarities which don't seem sane to me. Why do I
have write the .service suffix every time I want to manage a service?
I've seen the explanation that it handles other unit types like .path so
it's to differentiate but then why can't .service be the default if no
other unit type is specified?
If I try and stop a service that doesn't exist, why doesn't it complain?
Try it.
systemctl stop cheese.service
Great for those typos. Try starting a non existent service
systemctl start cheese.service
Failed to issue method call: Unit cheese.service failed to load: No such
file or directory. See system logs and 'systemctl status cheese.service'
for details.
Ok it warns you but then you get this:
systemctl -a | grep -i cheese
cheese.service error inactive dead cheese.service
Leads you to believe there should be a service called cheese and it's
failed for some reason. All this stuff is just weird and confusing IMO.
--
Ian Chapman.
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
