You are not logged in.
In anticipation of gnome 3.6 I decided to say my goodbyes to beloved rc.conf and switch to systemd today. It works fine so far and I am positively surprised by the improvements.
However, besides no longer having an rc.conf or inittab file, what else can I clean up? I'd like to get rid of all the legacy stuff (packages and config files alike) that systemd is handling anyway so I have a clearer idea of my system and don't end up tweaking in stuff there is no point in my tweaking anyway.
Offline
Hi there
To clean up things I installed the package called systemd-sysvcompat, which is conflicting with sysvinit, so, when you install it, it will prompt you to remove everything sysvinit left behind.
Best of Luck
PS. If you removed the previous initscripts and you already installed that package, you should be fine
"The way your heart sounds makes all the difference" John Myung
I love Dream Theater! ImL
Best Guitar Solo Ever
Offline
(...) PS. If you removed the previous initscripts and you already installed that package, you should be fine
Yes, but if one wants to go 'fully systemd', shouldn't systemd-sysvcompat be gone as well? That is my understanding, although I still have it lingering on my system 'just in case'...
Offline
I am thinking more of stuff like acpid and pm-utils. My impression is that systemd is meant to be replace these, but I am not sure if it really does.
Offline
I have rid myself of both of those things. I looked over my handler script w/ acpid and I realized that the only thing I had it doing anymore was suspending on lid close. Something easily handled by systemd. Also, the suspend mechanism for systemd works way faster than pm-utils. Presumably because w/ pm-utils you have all those scripts to run one after another before it finishes. With systemd, if you want to keep any of that functionality, convert those scripts to work w/ /usr/lib/systemd/system-sleep, and they actually all run in parallel.
Even if you have acpid doing a bit more complex things, there are definitely other ways to achieve them. For example, I have seen examples of people turning laptop-mode on and off w/ udev rules when a/c is (un)detected.
Offline
Silex89 wrote:(...) PS. If you removed the previous initscripts and you already installed that package, you should be fine
Yes, but if one wants to go 'fully systemd', shouldn't systemd-sysvcompat be gone as well? That is my understanding, although I still have it lingering on my system 'just in case'...
sysvcompat provides systemd symlinks to the following:
/sbin/halt
/sbin/init
/sbin/poweroff
/sbin/reboot
/sbin/runlevel
/sbin/shutdown
/sbin/telinit
Other than that, it doesn't really seem to do anything once installed.
Offline
Correct, it simply points any attempt by legacy stuff back to systemd, ensuring that there is no (or minimal) breakage.
Offline
I have rid myself of both of those things. I looked over my handler script w/ acpid and I realized that the only thing I had it doing anymore was suspending on lid close. Something easily handled by systemd. Also, the suspend mechanism for systemd works way faster than pm-utils. Presumably because w/ pm-utils you have all those scripts to run one after another before it finishes. With systemd, if you want to keep any of that functionality, convert those scripts to work w/ /usr/lib/systemd/system-sleep, and they actually all run in parallel.
Even if you have acpid doing a bit more complex things, there are definitely other ways to achieve them. For example, I have seen examples of people turning laptop-mode on and off w/ udev rules when a/c is (un)detected.
Thanks. This is the sort of thing I was thinking of.
I've gone ahead and removed acpid. Apparently, pm-utils is part of the dependency chain for half of my Unity packages (and the xfce power manager too), so it looks like I will be keeping that.
Offline
I kept pm-utils on my machine for reference to the scripts for a bit. But I put either symlinks or one line scripts in /usr/local/bin rebirecting pm-suspend and such to the appropriate systemd commands.
Though, now that I am looking, I really haven't ported any of those scripts from pm-utils to systemd, as I have not seen the need for any of it (yet?)
Offline
sysvcompat provides systemd symlinks to the following: (...)
Thanks, yes, but what needs to be done to get rid of systemd-sysvcompat? I can see from '$ systemctl list-unit-files' that I still have quite a few _disabled units, and wonder if there is a list somewhere explaining the units, including which of them are/are not advisable to be run simultaneously? I believe the ones marked 'static' are not meant to be enabled. I have read all of Poettering's systemd blog posts, but certain central things still escape me...
Offline
I noticed that I still have an /etc/rc.d/ folder full of scripts. I'm pure systemd as of today, so I'm wondering if I can just go ahead and delete /etc/rc.d/* ?
Edit: better not delete them. Just doing some pacman -Qo on the files: they are owned by various other packages. So, as far as I can tell they'll just sit there dormant and over the next few ages disappear when the corresponding packages are updated..
Last edited by headkase (2012-10-03 22:30:42)
Offline
b9anders wrote:sysvcompat provides systemd symlinks to the following: (...)
Thanks, yes, but what needs to be done to get rid of systemd-sysvcompat?
Just uninstall it, take a note and wait for something to break.
Offline
Already tried that and noted the system would not boot anymore At last I figured out I could use SystemRescueCD to boot into another Arch root partition and use 'pacman -r ....' to reinstall systemd-sysvcompat on my default system. So don't uninstall systemd-sysvcompat unless you know what to use in its place, whatever that might be...
Offline
$ pacman -Ql systemd-sysvcompat
systemd-sysvcompat /sbin/
systemd-sysvcompat /sbin/halt
systemd-sysvcompat /sbin/init
systemd-sysvcompat /sbin/poweroff
systemd-sysvcompat /sbin/reboot
systemd-sysvcompat /sbin/runlevel
systemd-sysvcompat /sbin/shutdown
systemd-sysvcompat /sbin/telinit
systemd-sysvcompat /usr/
systemd-sysvcompat /usr/share/
systemd-sysvcompat /usr/share/man/
systemd-sysvcompat /usr/share/man/man8/
systemd-sysvcompat /usr/share/man/man8/halt.8.gz
systemd-sysvcompat /usr/share/man/man8/poweroff.8.gz
systemd-sysvcompat /usr/share/man/man8/reboot.8.gz
systemd-sysvcompat /usr/share/man/man8/runlevel.8.gz
systemd-sysvcompat /usr/share/man/man8/shutdown.8.gz
systemd-sysvcompat /usr/share/man/man8/telinit.8.gz
Uninstalling systemd-sysvcompat is a bad idea. For example:
$ ls -l /sbin/init
lrwxrwxrwx 1 root root 26 Sep 27 22:28 /sbin/init -> ../usr/lib/systemd/systemd
Tells you that when your kernel executes init it will actually launch systemd for the boot process.
All systemd-sysvcompat is for is to map all the init things, like booting and shutting down over to systemd. Uninstall that package at your peril.
Awebb, perhaps next time for the sake of completeness you can suggest he run "sudo rm -r /" (DON'T run that)?
Last edited by headkase (2012-10-04 22:11:20)
Offline
If you look at the package's contents, they are all just symlinks. So I am sure it would be fairly easy to replace them with your own, and then remove the package. Though, headkase, you are right that you should not simply go removing things that you don't understand.
I would imagine if you are confident that nothing on your system depends on the shudown, poweroff, runlevel, etc. commands and you just added the init=/bin/systemd to your kernel command line, you don't actually need it.
Edit: better safe than sorry though... it is a whole 48kb, but that massive storage kill is worth it I think
Last edited by WonderWoofy (2012-10-05 00:39:51)
Offline
Yes init=/bin/systemd to the kernel line will enable boot - you can do this without a rescue cd even if you forgot to add it.
When you get the error telling you that the init couldn't be found (I forget the wording) and are dropped at the busybox prompt do the following:
1) Run mount and see what device is mounted as "new_root"
2) Unmount it and remount it with the option "-o rw"
3) chroot /new_root
4) Navigate to /boot/you boot loader folder config
5) Edit the file and add the init=/bin/systemd setting.
6) Reboot.
For the other stuff, wherever you refer to shutdown, reboot, etc. just change to point to systemctl plus the relevant command - poweroff, halt, reboot, etc.
But yeah, don't just jump in without looking - in this instance he who hesitates is not lost.
"...one cannot be angry when one looks at a penguin." - John Ruskin
"Life in general is a bit shit, and so too is the internet. And that's all there is." - scepticisle
Offline
(...)
4) Navigate to /boot/you boot loader folder config
5) Edit the file and add the init=/bin/systemd setting.
6) Reboot.
I assume you are referring to GRUB legacy here, i.e. menu.lst, and not GRUB2? The GRUB2 grub.cfg in /boot/grub "is automatically generated by grub-mkconfig using templates from /etc/grub.d and settings from /etc/default/grub". The admin/user is explicitly told not to edit this file.
For the other stuff, wherever you refer to shutdown, reboot, etc. just change to point to systemctl plus the relevant command - poweroff, halt, reboot, etc. (...)
Where would I change these for default use?
Offline
skanky wrote:(...)
4) Navigate to /boot/you boot loader folder config
5) Edit the file and add the init=/bin/systemd setting.
6) Reboot.I assume you are referring to GRUB legacy here, i.e. menu.lst, and not GRUB2? The GRUB2 grub.cfg in /boot/grub "is automatically generated by grub-mkconfig using templates from /etc/grub.d and settings from /etc/default/grub". The admin/user is explicitly told not to edit this file.
For the other stuff, wherever you refer to shutdown, reboot, etc. just change to point to systemctl plus the relevant command - poweroff, halt, reboot, etc. (...)
Where would I change these for default use?
I don't know grub2, sorry. I use syslinux which is like grub. I assume there's somewhere in grub2 where you can add kernel line parameters?
The other stuff will depend on your system and use (DE, WM, etc.). Anywhere that uses shutdown, etc. I don't have a DE, so for me it was just acpid handlers and aliases. Others might want to check menu items, etc.
On phone so this is a but vague, sorry.
"...one cannot be angry when one looks at a penguin." - John Ruskin
"Life in general is a bit shit, and so too is the internet. And that's all there is." - scepticisle
Offline
whaler wrote:skanky wrote:(...)
4) Navigate to /boot/you boot loader folder config
5) Edit the file and add the init=/bin/systemd setting.
6) Reboot.I assume you are referring to GRUB legacy here, i.e. menu.lst, and not GRUB2? The GRUB2 grub.cfg in /boot/grub "is automatically generated by grub-mkconfig using templates from /etc/grub.d and settings from /etc/default/grub". The admin/user is explicitly told not to edit this file.
For the other stuff, wherever you refer to shutdown, reboot, etc. just change to point to systemctl plus the relevant command - poweroff, halt, reboot, etc. (...)
Where would I change these for default use?
I don't know grub2, sorry. I use syslinux which is like grub. I assume there's somewhere in grub2 where you can add kernel line parameters?
The other stuff will depend on your system and use (DE, WM, etc.). Anywhere that uses shutdown, etc. I don't have a DE, so for me it was just acpid handlers and aliases. Others might want to check menu items, etc.
On phone so this is a but vague, sorry.
To add kernel parameters in grub 2 you can edit /etc/default/grub and edit the GRUB_CMDLINE_LINUX_DEFAULT=" "line, and then run grub-mkconfig again.
Last edited by bwat47 (2012-10-05 23:21:38)
Offline
To add kernel parameters in grub 2 you can edit /etc/default/grub and edit the GRUB_CMDLINE_LINUX_DEFAULT=" "line, and then run grub-mkconfig again.
Yes. My point was only the distinction between GRUB and GRUB2. As GRUB2 is gaining ground, I seem to see GRUB2 being increasingly referred to as just GRUB...
Offline
Just an extra note, it looks like the symlink /bin/symlink might be getting removed at some point in the future - though no timescale as yet. So if people are doing this now, they may just want set the init entry up to systemd in /usr/lib instead. Saves having to change it again in the future. Obviously there's nothing stopping people putting it back in themselves of course.
"...one cannot be angry when one looks at a penguin." - John Ruskin
"Life in general is a bit shit, and so too is the internet. And that's all there is." - scepticisle
Offline