6 ms·

Sounds great.. i'm using Debian on my Desktop and i would welcome such a move! Let the good old sys-v init system die, it has served long enough. I understand t

by buster 13y ago

Sounds great.. i'm using Debian on my Desktop and i would welcome such a move! Let the good old sys-v init system die, it has served long enough. I understand that most old init scripts would even work in systemd, so i imagine the migration not being as painful as it may seem..

viraptor 13y ago
I've got mixed feelings about this. I really like the idea behind systemd/upstart (they're quite similar in practice) and was glad to migrate to systemd when Arch sorted out most of its integration issues. But to be honest, I prefer upstart much more. It's simple, it does one thing, it's clear about what happens (most of the time). With systemd I find myself quite often with no idea where to even look for information about something not starting. I still have a service in the system that I don't know how to remove (it's failing to start apparently, not even sure where does it get created). I spent hours debugging issues and trying to get it all-green on my system... and failed. In my opinion it's just too big and complex for it's own good. For my deployments upstart provides the equivalent behaviour in the part that matters (actually running the software) in a simpler way and does not try anything else.
- fuzzix 13y ago
  "With systemd I find myself quite often with no idea where to even look for information about something not starting" You could read the (currently) 20-part sysadmin guide. http://0pointer.de/blog/projects/socket-activated-containers.html http://0pointer.de/blog/projects/socket-activated-containers... /sbin/init and its simple shell scripts never required this much explanation.
  - viraptor 13y ago
    I read (most of) it, but there's a big difference between "I know how this works" and "I can debug why things don't work as I expect them to work after reading documentation" with systemd. This gap doesn't exist with sysv style init scripts and I couldn't find much information addressing the issue.
    - bkor 13y ago
      You're confusing existing knowledge you already have with how easy another system is. Obviously if you already know one system, the other system will seem more difficult. I have had my fair share of daemons not starting due to various problems. E.g. openldap (terribly confusing debug messages). Give me systemd any day over the complexity of a lot of those scripts.
      - ldng 13y ago
        Had not seen your comment before adding mine but I think you're spot on. And having had to fight with openladp last week I can only agree with you. I used to know the "old" standard text file config and the new slap.d config style is confusing. But I think it's comparable to systemd in that if you manage an LDAP directory day to day, the new system probably makes more sens once you're used to it. We have to relearn the config and, man, sometimes we can be a lazy whiny bunch when we should try to evaluate systemd more objectively ;-) As an aside, the survey pleased me as I expected more conservatism from Debian
        bkor 13y ago
        I didn't mean the openldap config. Sometimes the daemon just plainly does not start. You basically have to resort to using strace to figure out what is wrong with the thing. Systemd redirects stderr and stdout, highly useful IMO. Openldap gives difficult to debug starting problems in loads of cases. E.g. problem in a certificate, config problem, etc. Then you might want to increase the debugging level. Really not fun to look into some script and figure out what actually eventually is passed to the openldap daemon as arguments.
  - qznc 13y ago
    Well, the systemd suite replaces a lot more than "/sbin/init and its simple shell scripts". It is no surprise that it has more documentation.
  - ldng 13y ago
    True. And I find myself struggling more than I'd like to tame the beast. That said, putting my devil's advocate hat on, if you and I were to start afresh not knowing shell, we'd struggle too. And truth be told, I'm not objective enough to tell if it's easier to learn shell programming or systemd config for a neophyte.
- nsmartt 13y ago
  I haven't used upstart, but this is exactly how I felt when using systemd on Arch.
- mseepgood 13y ago
  > I really like the idea behind systemd/upstart (they're quite similar in practice) They're quite different. Upstart is event-based while systemd is based on automatic dependency resolution and socket activation: http://www.youtube.com/watch?v=TyMLi8QF6sw&t=11m18s http://www.youtube.com/watch?v=TyMLi8QF6sw&t=11m18s
  - viraptor 13y ago
    I know they're different in how they are constructed. They're similar in what they do. For the majority of people who ever need to do anything with upstart/systemd it will be: it starts a service and its dependencies; it restarts the service that crashes if configured to do so; service operations can be triggered from outside. Yes, underneath they have completely different implementation, but it shouldn't really matter apart from OS-level edge cases. If it does matter, it's a sign they failed to provide a simple and usable tool in my opinion.
    - mseepgood 13y ago
      They are also different in practice. For example, you can kill services cleanly with systemd, because it keeps track of what processes belong to which service via CGroups.
      - viraptor 13y ago
        If you're interested in edge cases, then cgroup support can be included in your upstart configuration too. It's not a simple switch in the configuration, but can be made to work in the same way - I do that for some forking services which sometimes fail to collect children properly. I wouldn't consider this to be a big difference between the systems - each has some features that the other doesn't.
    - jeltz 13y ago
      I have not used systemd in practice but my experiences with upstart in practice are very different from both sysvinit and from what I read about systemd. I actually think systemd seems to be closer to sysvinit than to upstart. EDIT: It is the reversed dependency logic in upstart which makes it so different from anything else.
- bkor 13y ago
  Could be be more concrete what service is failing? Systemd for me always gives really good output on why things aren't working.

by buster 13y ago

viraptor 13y ago

I've got mixed feelings about this. I really like the idea behind systemd/upstart (they're quite similar in practice) and was glad to migrate to systemd when Arch sorted out most of its integration issues. But to be honest, I prefer upstart much more. It's simple, it does one thing, it's clear about what happens (most of the time). With systemd I find myself quite often with no idea where to even look for information about something not starting. I still have a service in the system that I don't know how to remove (it's failing to start apparently, not even sure where does it get created). I spent hours debugging issues and trying to get it all-green on my system... and failed. In my opinion it's just too big and complex for it's own good. For my deployments upstart provides the equivalent behaviour in the part that matters (actually running the software) in a simpler way and does not try anything else.

fuzzix 13y ago
"With systemd I find myself quite often with no idea where to even look for information about something not starting" You could read the (currently) 20-part sysadmin guide. http://0pointer.de/blog/projects/socket-activated-containers.html http://0pointer.de/blog/projects/socket-activated-containers... /sbin/init and its simple shell scripts never required this much explanation.
- viraptor 13y ago
  I read (most of) it, but there's a big difference between "I know how this works" and "I can debug why things don't work as I expect them to work after reading documentation" with systemd. This gap doesn't exist with sysv style init scripts and I couldn't find much information addressing the issue.
  - bkor 13y ago
    You're confusing existing knowledge you already have with how easy another system is. Obviously if you already know one system, the other system will seem more difficult. I have had my fair share of daemons not starting due to various problems. E.g. openldap (terribly confusing debug messages). Give me systemd any day over the complexity of a lot of those scripts.
    - ldng 13y ago
      Had not seen your comment before adding mine but I think you're spot on. And having had to fight with openladp last week I can only agree with you. I used to know the "old" standard text file config and the new slap.d config style is confusing. But I think it's comparable to systemd in that if you manage an LDAP directory day to day, the new system probably makes more sens once you're used to it. We have to relearn the config and, man, sometimes we can be a lazy whiny bunch when we should try to evaluate systemd more objectively ;-) As an aside, the survey pleased me as I expected more conservatism from Debian
      - bkor 13y ago
        I didn't mean the openldap config. Sometimes the daemon just plainly does not start. You basically have to resort to using strace to figure out what is wrong with the thing. Systemd redirects stderr and stdout, highly useful IMO. Openldap gives difficult to debug starting problems in loads of cases. E.g. problem in a certificate, config problem, etc. Then you might want to increase the debugging level. Really not fun to look into some script and figure out what actually eventually is passed to the openldap daemon as arguments.
- qznc 13y ago
  Well, the systemd suite replaces a lot more than "/sbin/init and its simple shell scripts". It is no surprise that it has more documentation.
- ldng 13y ago
  True. And I find myself struggling more than I'd like to tame the beast. That said, putting my devil's advocate hat on, if you and I were to start afresh not knowing shell, we'd struggle too. And truth be told, I'm not objective enough to tell if it's easier to learn shell programming or systemd config for a neophyte.
nsmartt 13y ago
I haven't used upstart, but this is exactly how I felt when using systemd on Arch.
mseepgood 13y ago
> I really like the idea behind systemd/upstart (they're quite similar in practice) They're quite different. Upstart is event-based while systemd is based on automatic dependency resolution and socket activation: http://www.youtube.com/watch?v=TyMLi8QF6sw&t=11m18s http://www.youtube.com/watch?v=TyMLi8QF6sw&t=11m18s
- viraptor 13y ago
  I know they're different in how they are constructed. They're similar in what they do. For the majority of people who ever need to do anything with upstart/systemd it will be: it starts a service and its dependencies; it restarts the service that crashes if configured to do so; service operations can be triggered from outside. Yes, underneath they have completely different implementation, but it shouldn't really matter apart from OS-level edge cases. If it does matter, it's a sign they failed to provide a simple and usable tool in my opinion.
  - mseepgood 13y ago
    They are also different in practice. For example, you can kill services cleanly with systemd, because it keeps track of what processes belong to which service via CGroups.
    - viraptor 13y ago
      If you're interested in edge cases, then cgroup support can be included in your upstart configuration too. It's not a simple switch in the configuration, but can be made to work in the same way - I do that for some forking services which sometimes fail to collect children properly. I wouldn't consider this to be a big difference between the systems - each has some features that the other doesn't.
  - jeltz 13y ago
    I have not used systemd in practice but my experiences with upstart in practice are very different from both sysvinit and from what I read about systemd. I actually think systemd seems to be closer to sysvinit than to upstart. EDIT: It is the reversed dependency logic in upstart which makes it so different from anything else.
bkor 13y ago
Could be be more concrete what service is failing? Systemd for me always gives really good output on why things aren't working.