Sander Jansen (2011-01-20 19:09): > On Thu, Jan 20, 2011 at 6:55 PM, Yaro Kasear <yaro@xxxxxxxxxx> wrote: > > On Thursday, January 20, 2011 06:48:14 pm Sander Jansen wrote: > > (snip) > >> > >> - It's nice you can install it next to sysv-init. This makes it really > >> easy to test without breaking the system. > > > > You can do this? I might try it out. If it works as expected in its stage of > > development, I'll quick being a jerk about it. > > > > Also, how does that work? Do you choose an init at some point? > > See the wiki, it's a kernel boot parameter. By default, Linux kernel runs /sbin/init as PID 1 (the first user level process). This can be changed by adding init=/binary/to/run to the kernel command line. The command line can be changed in the kernel config, in the boot loader config or during boot in grub, lilo, syslinux, etc. For example, in grub one sees "kernel /boot/vmlinuz26 root=/dev/sda5 ro". One can append this to change what the kernel starts: init=/sbin/init init=/bin/systemd init=/bin/bash > >> - I guess the initscripts-systemd is listed as an optional dependency > >> of systemd, but I'm not sure how usefull systemd is without it...? > > > > Though I don't 100% know how systemd is, don't all init systems need scripts > > to be useful? I would think that installing systemd's initscripts would be > > important for it to do its work. > > Yeah, this is more a packaging issue. If you compile and install the upstream systemd source, you can reboot into a working system (it comes with a bunch of streamlined unit files needed for early boot). In fact, systemd is pretty good at not requiring any unit files: you can launch it with only one unit file for getty and have a working system. These initscripts-systemd are used as a bridge between systemd and some of the early boot scripts in Arch. > >> - The login console seems to be slightly messed up. I can login, but > >> error/log messages keep being send to the terminal as well. > > > > What are the messages? Is there a bug in the bug tracker about this or is this > > purely an upstream concern? > > Just stderr output from the various daemons running. I'm guessing it > goes to the wrong terminal. This probably means that systemd was unable to start syslogd or doesn't know about it. Which one do you use? Is it running? > >> - I know how I can change the default target on the boot line, but can > >> I set it anywhere else? /lib/systemd/system/ has a symlink: default.target -> graphical.target You can create /etc/systemd/system/default.target to override it. > >> - sshd has listed network.service as a dependency, but what if you use > >> NetworkManager instead? > > > > Would this be cause for a seperate set of daemon scripts just for systemd or > > are there plans to make it work with rc.conf in much the same way SysV does? > > systemd has "unit" files that replace the traditional sysv daemon > scripts. They're much shorter and sweeter. The question was related to > whether sshd should list "network" which is arch's /etc/rc.d/network > script as a dependency. Some of them are not so sweet. In fact, most of the advanced functions (e.g. on demand service startup, fine tuning dependencies) are difficult to grasp and the help is scattered over a handful of man pages. All of the advertised features of systemd bring a lot of complexity with them. -- -- Rogutės Sparnuotos
