Should the section "writing a custom .service" be expanded?
I think so.. as long as I got, this is necessary to run self-made scripts during the boot process, but this is not clear and the structure of the files is not well presented.
Moreover, when explain how to transit from the initscript, some referrals on how to move the old custom hooks in /etc/rc.d/functions.d to be executed by systemd, should be made.
Display manager fails to load with fast SSD
I was having a problem with my display manager (LXDM) not loading on my laptop, which has a Sandisk Extreme SSD. Xorg.log would show errors like "No screens found."
I eventually figured out that the problem was that my computer was booting so fast that KMS didn't have enough time to kick in before X was started. I solved by adding the KMS driver (i915 in my case) to the initramfs.
- This is a general problem that needs to be solved in the display manager. GDM already implements the bits for the CanGraphical flag.
- -- Falconindy (talk) 21:34, 2 September 2012 (UTC)
Should we add a note about CUPS under 'Transitioning from initscripts to systemd'?
Are there any more sockets that change?
Copied from the CUPS wiki:
Systemd uses a different CUPS socket file located at:
The default CUPS socket file is located at:
/etc/cups/client.conf as root to use the systemd socket instead of the default. Make sure to restart CUPS when you are done:
# systemctl restart cups
-- JKAbrams 5 November 2012
- This sounds more like a packaging bug that should just be fixed.
- -- Jstjohn (talk) 01:11, 8 November 2012 (UTC)
Still reading up on this, so I'm not 100% solid but I discovered during the systemd transition that it defaults the / mount to rshared (see Shared subtree for definitions, and core/mount_setup.c in systemd for the actual code). This means that all bind mounts made through fstab will default to shared behavior, not private. For those users who depend on non-recursive bind mounts, this can be a very big gotcha (as the mount propagation effectively nullifies the non-recursion).
For nested bind mounts, this also results in multiplicative bloat of the mount table, depending on what kind of nesting structure is used (it's actually relatively easy to construct a nesting sequence that makes 2^n mounts out of n mount calls).
Setting aside whether this behavior is a good idea or not, it's definitely a good thing to note under Filesystem Mounts, since fstab bind entries definitely may not preserve behavior across the systemd transition. I didn't find any documentation of this particular gotcha elsewhere, so I think the addition would be justified, since some systems can definitely fail to boot as a result of this.
Still looking into good (and easy) configuration solutions.