You are not logged in.

#1 2012-08-26 01:28:31

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 5,663

Replicating /etc/rc.d/* and pm-utils functionality with systemd

Caveat: I have not yet gone so far as to actually try systemd although I have installed it to have a poke around.

I've been reading up on systemd because I would prefer to switch now (during the summer) than try to switch later (during the semester). Despite the likely idiocy of my questions, I have actually read a reasonable amount about systemd at this point although I'm not really sure I've got a grip on it yet. I just figured a bank holiday weekend which is wet and windy was as good a time as any...

I know that I can, for now, continue to use the DAEMONS line in /etc/rc.conf. I'm guessing this will use the scripts in /etc/rc.d/* although I haven't checked this yet.

But assuming I wanted to do things the systemd way, I gather that I would enable .services of various kinds. These roughly correspond to the scripts in /etc/rc.d/*.

I also understand that "enable" actually installs the service so that the setting survives a reboot.

So far, so good.

/etc/rc.d/* vs. /usr/lib/systemd/system/*
-----------------------------------------------
So I started reading some of the .service files I thought I'd need from /usr/lib/systemd/system/* and comparing them with the daemon scripts I'm currently using under /etc/rc.d/*. I noticed that many of these don't appear to offer equivalent functionality, especially in terms of the ability to set custom options and arguments in /etc/conf.d and so on. For example, I was looking at clamd.service and freshclamd.service as replacements for clamav; rfkill.service as a replacement for rfkill; and so on. Whereas the rc.d scripts source the config files under /etc/conf.d, these .service files do not seem to do so.

Does this mean that in order to switch to systemd, I should do something like creating customised versions of those .service files? (Somewhere under /etc/, maybe?) Or have I missed something obvious? [This is very likely - I got a bit lost with units, targets, services and other unfamiliar terminology.]

/etc/pm/{sleep|power}.d/* vs. /usr/lib/systemd/system-sleep/*
-------------------------------------------------------------------------
Also, I don't have any custom hooks for pm-utils but alsa-utils installed one under /etc/pm/sleep.d. And I installed a bunch of empty files under /etc/power.d to prevent pm-utils conflicting with laptop-mode-tools, I think. [I'm not entirely clear how laptop-mode-tools engages with systemd but I know there's a service so I assume they coexist sufficiently peaceably.]

I read that custom sleep hooks should go under /usr/lib/systemd/system-sleep and I'd just like to clarify if I've understood that correctly. Are custom hooks really meant to go under /usr/lib rather than, say /etc? That seems rather untidy to me but perhaps there's a good reason for it. More likely, though, I've just misunderstood something.


How To Ask Questions The Smart Way | Help Vampires

Arch Linux | x86_64 | GPT | EFI boot | grub2 | systemd | LVM2 on LUKS
Lenovo x121e | Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz GenuineIntel | Intel Centrino Wireless-N 1000 | US keyboard with Euro | 320G 7200 RPM Seagate HDD

Offline

#2 2012-08-26 01:42:43

progandy
Member
Registered: 2012-05-17
Posts: 2,151

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

cfr wrote:

Does this mean that in order to switch to systemd, I should do something like creating customised versions of those .service files? (Somewhere under /etc/, maybe?) Or have I missed something obvious? [This is very likely - I got a bit lost with units, targets, services and other unfamiliar terminology.]

There exists the directive EnvironmentFile to set variables according from a file in conf.d Here is an example. Of course you can always create a custom file in /etc directly with the options or adding the missing EnvironmentFIle to override the original.

Offline

#3 2012-08-26 02:01:26

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 5,663

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

Thanks very much. Is that in the man pages anywhere? I'd been through the pages for systemd.service, systemd and systemd.unit (which seemed most likely) but didn't see this key listed. (Though the some of the pages are quite long so I'm not saying I didn't miss it.)

So what I would need to do for clamav, say, would be to create /etc/systemd/system/clamd.service. Then when I enable clamd.service, systemd will use my customised version rather than the default /usr/lib/systemd/system/clamd.service? Or will creating the file itself enable the service in that case?
EDIT: Answer to first question here seems to be yes (http://0pointer.de/blog/projects/three- … f-off.html). Still not clear about the man pages or the enabling bit. I'm also a bit worried that disabling the service will then delete the custom file. Maybe it is better to set up a separate directory of custom .service files and symlink there?

Last edited by cfr (2012-08-26 02:25:46)


How To Ask Questions The Smart Way | Help Vampires

Arch Linux | x86_64 | GPT | EFI boot | grub2 | systemd | LVM2 on LUKS
Lenovo x121e | Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz GenuineIntel | Intel Centrino Wireless-N 1000 | US keyboard with Euro | 320G 7200 RPM Seagate HDD

Offline

#4 2012-08-26 02:25:20

progandy
Member
Registered: 2012-05-17
Posts: 2,151

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

cfr wrote:

Thanks very much. Is that in the man pages anywhere? I'd been through the pages for systemd.service, systemd and systemd.unit (which seemed most likely) but didn't see this key listed. (Though the some of the pages are quite long so I'm not saying I didn't miss it.)

I did not find it either. The best description is the fedora wiki I think.

So what I would need to do for clamav, say, would be to create /etc/systemd/system/clamd.service. Then when I enable clamd.service, systemd will use my customised version rather than the default /usr/lib/systemd/system/clamd.service? Or will creating the file itself enable the service in that case?

systemd reads files in this order: /etc, /run, /usr/lib Files in /etc overrides /run and /usr/lib, /run overrides /usr/lib. Other than that all directory structures behave exactly the same. So you will have to (re)enable clamav.service.

Offline

#5 2012-08-26 02:30:24

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 5,663

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

Thank you. The Fedora wiki looks extremely helpful - it is a bit more basic than some of the other stuff I've found online which is really what I need right now to get some sort of overview of the whole thing. smile


How To Ask Questions The Smart Way | Help Vampires

Arch Linux | x86_64 | GPT | EFI boot | grub2 | systemd | LVM2 on LUKS
Lenovo x121e | Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz GenuineIntel | Intel Centrino Wireless-N 1000 | US keyboard with Euro | 320G 7200 RPM Seagate HDD

Offline

#6 2012-08-26 05:56:51

Zancarius
Member
From: NM, USA
Registered: 2012-05-06
Posts: 207

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

cfr wrote:

Thanks very much. Is that in the man pages anywhere?

systemd.exec(5)

Edit: Other man pages of interest:

systemd.unit
systemd.service

Also possibly (for advanced use):

systemd.mount
systemd.automount
systemd.kill

Last edited by Zancarius (2012-08-26 05:57:54)


He who has no .plan has small finger.
~Confucius on UNIX.

Offline

#7 2012-08-26 09:39:39

65kid
Member
From: Germany
Registered: 2011-01-26
Posts: 663

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

Does this mean that in order to switch to systemd, I should do something like creating customised versions of those .service files? (Somewhere under /etc/, maybe?) Or have I missed something obvious? [This is very likely - I got a bit lost with units, targets, services and other unfamiliar terminology.

while EnvironmentFile= provides a similiar mechanism, the devs actually want to get rid of /etc/conf.d/* files. So yes, if you want to override / add options, copy the unit from /usr to /etc and edit it or ".include" the unit from /usr and override ExecStart= or whatever .
see https://wiki.archlinux.org/index.php/Sy … it_file.3F

I read that custom sleep hooks should go under /usr/lib/systemd/system-sleep and I'd just like to clarify if I've understood that correctly. Are custom hooks really meant to go under /usr/lib rather than, say /etc? That seems rather untidy to me but perhaps there's a good reason for it. More likely, though, I've just misunderstood something.

I also find /usr a little strange for this, maybe this has something to do with this (from man systemd-sleep):

Note that scripts or binaries dropped in /usr/lib/systemd/system-sleep/ are intended for local use only and should be considered hacks. If applications want to be notified of system suspend and resume there are much nicer interfaces available.

Offline

#8 2012-08-26 18:32:45

Zancarius
Member
From: NM, USA
Registered: 2012-05-06
Posts: 207

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

65kid wrote:

Does this mean that in order to switch to systemd, I should do something like creating customised versions of those .service files? (Somewhere under /etc/, maybe?) Or have I missed something obvious? [This is very likely - I got a bit lost with units, targets, services and other unfamiliar terminology.

while EnvironmentFile= provides a similiar mechanism, the devs actually want to get rid of /etc/conf.d/* files. So yes, if you want to override / add options, copy the unit from /usr to /etc and edit it or ".include" the unit from /usr and override ExecStart= or whatever .
see https://wiki.archlinux.org/index.php/Sy … it_file.3F

Source discussion for what 65kid is talking about. In particular it appears, and rightfully so, that they're encouraging developers to read in their own configuration files rather than relying on setting some env vars prior to launch.


He who has no .plan has small finger.
~Confucius on UNIX.

Offline

#9 2012-08-27 02:29:00

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 5,663

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

Zancarius wrote:

systemd.exec(5)

Ah. Thank you. That certainly wasn't obvious - not to me anyway. I tend to think the variables I can set in a config file will be pretty much in one man page but I guess not.

Edit: Other man pages of interest:

systemd.unit
systemd.service

Yes. As I said, I found these - which was why I was confused I hadn't come across the EnvironmentFile key.

Also possibly (for advanced use):

systemd.mount
systemd.automount
systemd.kill

I think if the rest is "basic use", I'd definitely better avoid these for now smile.


How To Ask Questions The Smart Way | Help Vampires

Arch Linux | x86_64 | GPT | EFI boot | grub2 | systemd | LVM2 on LUKS
Lenovo x121e | Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz GenuineIntel | Intel Centrino Wireless-N 1000 | US keyboard with Euro | 320G 7200 RPM Seagate HDD

Offline

#10 2012-08-27 02:44:16

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 5,663

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

I was assuming, actually, that I'd create customised .service files even to use EnvironmentFile since I don't want to change the originals under /usr/lib.

Right now I'm using that option and sourcing /etc/conf.d. I'm not currently ready to abandon the option of booting with initscripts so it is simpler to be able to edit config in one place when possible. (And some "official" .service files already do this.) I've no intention of abandoning initscripts completely until systemd can boot into an emergency shell. So far, I've created custom service files for:

alsa-restore.service
alsa-store.service
cronie.service
freshclamd.service
kdm.service
rfkill-unblock.service
syslog-ng.service

I'm not sure these are all necessary but still. rfkill is a major problem, though as I've no idea how to replicate the functionality from rc.d with systemd. The standard rfkill.service file does something completely different if I've understood it correctly. My current attempt is a kludge and will fail in various cases. I think I would need a script to do what the rc.d rfkill script does which seems to undermine the point of using systemd. I'm sure there's another way but there doesn't seem to be any obvious or straightforward way.

Is it just me or is systemd much harder to learn than sysvinit? It feels more and more like launchd - theoretically very straightforward but actually rather difficult to use to do whatever you happen to want it to do. (And so you end up using Startup Items and so on in addition to launchd and then boot is even harder to disentangle.) Maybe it is just a transitional phase... (I expect launchd has improved by now, for example.)


How To Ask Questions The Smart Way | Help Vampires

Arch Linux | x86_64 | GPT | EFI boot | grub2 | systemd | LVM2 on LUKS
Lenovo x121e | Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz GenuineIntel | Intel Centrino Wireless-N 1000 | US keyboard with Euro | 320G 7200 RPM Seagate HDD

Offline

#11 2012-08-27 04:54:30

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,412

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

I think that it is still in the transitional stage.  You have to consider that sysv has had quite some time to get to the point where it is as easy to use as it is now.  I guess this is best exemplified by the service files you noticed were missing. 

As for the system-sleep, the only thing I found kind of annoying is that netcfg did not autmatically reconnect when I resumed from sleep so I added this

if [[ $1 == 'pre' ]] && [[ $2 == 'suspend' ]] ; then
	netcfg all-suspend
elif [[ $1 == 'pre' ]] && [[ $2 == 'hibernate' ]] ; then
	netcfg all-suspend
elif [[ $1 == 'post' ]] && [[ $2 == 'suspend' ]] ; then
	netcfg all-resume
elif [[ $1 == 'post' ]] && [[ $2 == 'hibernate' ]] ; then
        netcfg all-resume
fi

I did not add anything else because I went through powertop, googled, and fixed all the real powerdraws on my system.  So I no longer use any power management scripts, and comparing what was left in sleep.d, I didn't see anything that I felt really needed to be in system-sleep.

Last edited by WonderWoofy (2012-08-27 04:55:10)

Offline

#12 2012-08-27 16:30:21

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 5,663

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

Thanks. I'll bear that in mind if I have similar issues. I mainly use laptop-mode-tools for power-related stuff. Basically because I want it to automate switches when I go AC -> battery -> low battery -> AC etc. and acpid to manage suspend etc. (Actually, I think KDE handles the switch to low battery but laptop-mode-tools handles most of the rest.)

So I took a deep breath and rebooted. Booting still works fine with initscripts. Better, in fact, because I've fixed an issue in fstab.

systemd isn't quite so successful. It does boot which I'm quite surprised by. (I expected to have made some egregious error and for it not to work at all.) However, I get some failures and it hangs for a long time on something.

$ systemctl --failed
UNIT                   LOAD   ACTIVE SUB    JOB DESCRIPTION
alsa.service           loaded ESC[1;31mfailed failedESC[0m     Legacy unit for alsa
rfkill-unblock.service loaded ESC[1;31mfailed failedESC[0m     RFKill-Unblock Selected Devices
syslog-ng.service      loaded ESC[1;31mfailed failedESC[0m     System Logger Daemon
syslog.socket          loaded ESC[1;31mfailed failedESC[0m     Syslog Socket

I can't find alsa.service on my system - only alsa-store.service and alsa-restore.service. I'm assuming something is trying to pull in alsa.service which shouldn't be. Maybe something has not been updated? But it could equally be a configuration error on my part.

This was my attempt to rfkill unblock stuff:

$ less /etc/systemd/system/rfkill-unblock.service 
[Unit]
Description=RFKill-Unblock Selected Devices

[Service]
Type=oneshot
EnvironmentFile=-/etc/conf.d/rfkill
ExecStart=/usr/bin/rfkill unblock ${RFKILL_UNBLOCK:-all}
ExecStop=
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

There are at least two things in this I wasn't sure about - one is whether systemd understands more than simple substitution on the variable and the other was whether it works to have an empty value for ExecStop. So I'm guessing one or both of those is the problem. Despite this, everything seems to be unblocked on my machine.

I'm not sure about the syslog-ng issue but I suspect it's a substitution thing again...


How To Ask Questions The Smart Way | Help Vampires

Arch Linux | x86_64 | GPT | EFI boot | grub2 | systemd | LVM2 on LUKS
Lenovo x121e | Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz GenuineIntel | Intel Centrino Wireless-N 1000 | US keyboard with Euro | 320G 7200 RPM Seagate HDD

Offline

#13 2012-08-27 20:32:04

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 5,663

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

Update/Notes to self:

systemd understands only two kinds of variable substitution in .service files, at least:

$var
${var}

The first treats whitespace in $var as an argument deliminator; the second includes such whitespace in the argument so ${var} is treated as a single (~quoted) argument. It is fairly simple-minded about variables, it seems.

So my rfkill-unblock.service won't work for two reasons: first, systemd can't deal with ${RFKILL_UNBLOCK:-all}; second, rfkill isn't in /usr/bin. The following file works (at least, it starts - haven't tried it at boot but I assume that's a good test):

$ cat /etc/systemd/system/rfkill-unblock.service 
[Unit]
Description=RFKill-Unblock All Devices

[Service]
Type=oneshot
ExecStart=/usr/sbin/rfkill unblock all
ExecStop=
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Note that I abandoned sourcing the config file for now - just unblock everything. Given that my hardware was unblocked on reboot anyway, I'm not sure if I even need this. Maybe systemd deals with this anyway? Or maybe a bios update has changed how this works... But better be safe than sorry, I guess. (Especially since bluetooth is a PITA to reenable on this machine if it gets blocked - basically, I have to render it unbootable by deleting the efi boot menu in order to reset all bios settings to defaults. Ridiculous.)

I figured I'd just dump the custom syslog-ng.service since it turns out I wasn't setting anything in the config file anyway. (Though I'd like to know how to get it to work even if I don't need to do so. smile)

So that leaves me with two issues: a looonnnggg hang on boot and one failed unit:

$ systemctl --failed
UNIT         LOAD   ACTIVE SUB    JOB DESCRIPTION
alsa.service loaded ESC[1;31mfailed failedESC[0m     Legacy unit for alsa

My sound seems to work, though - I tested it in KDE settings and it tests OK. If anybody has any idea what I might need alsa.service for or where I might find it, I'd really appreciate a pointer. locate doesn't find it - maybe it is an alias set somewhere?

I'm not sure if this causes the hang at boot or not. I've tweaked my fstab again and am about to reboot to see if that has any effect.

EDIT: Reboot did not hang. Well, it stuttered and got stuck but I don't think that's systemd's fault. (Just means that the BIOS update did not solve this issue and I'd been hoping it had.)

So, it seems that including comment=systemd.automount in the options for partitions on a not-always-present removable drive in fstab causes boot to stall. That is "nofail,noauto" works OK but "nofail,noauto,comment=systemd.automount" stalls. I assume it wouldn't do that with an existent partition of my internal disk but I haven't tried that.

Weirdly, I no longer see the above failure for alsa.service. Is it possible that it fails if sound is MUTED at boot? I've noticed that recently (even with initscripts), I started getting complaints about the default device not working even though testing showed it worked perfectly well. Does it take muted volume as a failure for some reason? Why?

Last edited by cfr (2012-08-27 20:43:30)


How To Ask Questions The Smart Way | Help Vampires

Arch Linux | x86_64 | GPT | EFI boot | grub2 | systemd | LVM2 on LUKS
Lenovo x121e | Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz GenuineIntel | Intel Centrino Wireless-N 1000 | US keyboard with Euro | 320G 7200 RPM Seagate HDD

Offline

#14 2012-08-27 22:35:03

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 5,663

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

One further question, is it normal for a systemd system to use an extra tty? After boot, with initscripts, tty1 has a regular cli login (as do ttys 2-6) and tty7 has the graphical login provided by kdm.

With systemd, after boot, tty1 seems to be unusable. The end of the boot messages fill the screen but no login appears. It is impossible to scroll up the screen (as far as I can tell) or to do anything else with it. The graphical login appears on tty7 and I can trigger cli logins on ttys 2-6 on demand, I believe, but tty1 is sort of "used up" by systemd.

Not that this is a huge deal. I just wondered if it is normal and why it would work that way.

I'm also not complaining about this but systemd seems no faster - and possibly slower - at boot. Once booted, I don't see any difference in responsiveness so far. As I say, I'm not especially bothered about this (at least the booting - a more responsive system is always nicer!) but am slightly surprised.

Last edited by cfr (2012-08-27 22:37:28)


How To Ask Questions The Smart Way | Help Vampires

Arch Linux | x86_64 | GPT | EFI boot | grub2 | systemd | LVM2 on LUKS
Lenovo x121e | Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz GenuineIntel | Intel Centrino Wireless-N 1000 | US keyboard with Euro | 320G 7200 RPM Seagate HDD

Offline

#15 2012-08-27 23:38:27

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,412

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

I think that it probably seems slower because it is failing some stuff.  So despite it parallelizing like crazy it is still waiting to see if some of those failures somehow succeed before dropping you into kdm. 

It sounds like you are using the hybrid systemd and initscripts.  I never did this, instead just opting for a pure systemd.  It should be noted though that my computer is pretty new, so my installation was pretty fresh.  I think the alsa.service, since it is referring to it as a legacy service is actually your rc.d script is is trying to handle for you.  I imagine that if you haven't fully moved to systemd, you still have a daemons array in a still existing rc.conf.  So yes, youare right, alsa-store.service and alsa-restore.service is what is used.  I think what it does is actuallly store your volume levels upon exit, and then restores to its revious value on next boot.  I think this may be a better way of handling things.  I also think that this is something that it does on its own, since I never actually enabled these services, yet they run on my system.

As far as syslog-ng, just stop using it.  Systemd comes with its own journal implementation.  Just run a journalctl as root to see your journal (also any user can see the journal if they are part of the adm group).  Beware though that the journal is volatile unless you set it to be otherwise.  To make it persistent, all you have to do is creadt /var/log/journal (or delete it to make it single sessoin once again).

I really don't use the rfkill on my machine, as i never have problems with having things blocked or not, and if I do want to kill my wifi, I just use the wifi kill button that all thinkpads come with.  To me your second rendition of the rfkill service seems right (though I am still trying to fully figure out all the ins and outs of writing serivices as well).

You know, I am not sure about your system, but mine is noticably better in terms of responsiveness, and the boot time was faster as well.  Though it has slowed a bit since first systemd boot because I have enabled a few services.  But I usually keep a pretty light system.  I don't use a login manager or anything like that.  I just have systemd automatically log me in, and then have my zshrc start dwm for me.  Then I just password protect my computer through the bios, and I figure its good enough (in fact I have the password disabled at the moment since my computer has not been leaving the house lately).

Snother things I was also able to do away with is acpid.  Like you (it sounds like anyway), I only used acpid to set my system to sleep on lid close.  Systemd actually has this function built in.  It can do sleep on lid close as well as  rudementary power and sleep button functions.  It is nothing fancy, but I figure there is no use in running another service if I don't ahve to.  At the moment I only have my power button set to work in the event that there are no users logged in, though there are a few other variables you can use.

I will try to keep up with your "systemd flow of consciousness" seen above to see if I can answer any more questions.  I think you are a very active and respectable member of the community, and am happy to throw ideas back and forth with you.

Offline

#16 2012-08-28 00:13:20

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 5,663

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

WonderWoofy wrote:

I think that it probably seems slower because it is failing some stuff.  So despite it parallelizing like crazy it is still waiting to see if some of those failures somehow succeed before dropping you into kdm.

I think the first time, that was surely true. The second time, though, I didn't get any failures. Not even alsa.service!

It sounds like you are using the hybrid systemd and initscripts.  I never did this, instead just opting for a pure systemd.

Yes and no. I'm not trying to but your saying this made me poke around a bit and I think that is quite likely. What I tried to do was set up the system so that I could boot either with pure(ish) systemd or with initscripts. Well, the latter bit seems to work! I think I need to mask arch-daemons.target to set it up more correctly. (So now I get to try to figure out how to do this - I think something about /dev/null is involved...)

It should be noted though that my computer is pretty new, so my installation was pretty fresh.  I think the alsa.service, since it is referring to it as a legacy service is actually your rc.d script is is trying to handle for you.  I imagine that if you haven't fully moved to systemd, you still have a daemons array in a still existing rc.conf.

But in that case, it shouldn't fail anyway, right?

What is weird is that it seems to fail if, and only if, sound is muted at boot.

So yes, youare right, alsa-store.service and alsa-restore.service is what is used.  I think what it does is actuallly store your volume levels upon exit, and then restores to its revious value on next boot.  I think this may be a better way of handling things.

The original rc.d script does this, too, but it does so in a slightly more customisable way and also offers some further options.

I also think that this is something that it does on its own, since I never actually enabled these services, yet they run on my system.

Yes, I think this is true. They don't have an "Install" section which I gather means they aren't meant to be enabled.

As far as syslog-ng, just stop using it.  Systemd comes with its own journal implementation.  Just run a journalctl as root to see your journal (also any user can see the journal if they are part of the adm group).  Beware though that the journal is volatile unless you set it to be otherwise.  To make it persistent, all you have to do is creadt /var/log/journal (or delete it to make it single sessoin once again).

No smile. I want plain text logs which I can view provided I can boot anything at all. That means they must be viewable if I boot with initscripts, if I boot finnix, if I boot from a random linux usb key or if, for some reason best known to myself, I decide to install and successfully boot darwin. It also means that output from scripts which I send to log files is readable in precisely the same way. This is make-or-break for me - the idea of binary log files is one I find positively terrifying. I have fairly frequently read log files from quite minimal environments and one of the few things you can be sure to have is some form of cat/less/more.

I really don't use the rfkill on my machine, as i never have problems with having things blocked or not, and if I do want to kill my wifi, I just use the wifi kill button that all thinkpads come with.  To me your second rendition of the rfkill service seems right (though I am still trying to fully figure out all the ins and outs of writing serivices as well).

Yes, systemd seems happier now. I'm less happy because it is less flexible but...

You know, I am not sure about your system, but mine is noticably better in terms of responsiveness, and the boot time was faster as well.  Though it has slowed a bit since first systemd boot because I have enabled a few services.  But I usually keep a pretty light system.  I don't use a login manager or anything like that.  I just have systemd automatically log me in, and then have my zshrc start dwm for me.  Then I just password protect my computer through the bios, and I figure its good enough (in fact I have the password disabled at the moment since my computer has not been leaving the house lately).

I know I should use bios security but it worries me. And I should have an encrypted disk drive but it worries me. I'm not bothered about boot time. I mean, when systemd was hanging for minutes on fails, that was clearly beyond the acceptable, but if it needs to take a bit longer to boot than initscripts, I'm not fussed. And my system isn't unresponsive most of the time anyway. (Not by my standards, anyway - my previous laptop was a G4.)

Snother things I was also able to do away with is acpid.  Like you (it sounds like anyway), I only used acpid to set my system to sleep on lid close.  Systemd actually has this function built in.  It can do sleep on lid close as well as  rudementary power and sleep button functions.  It is nothing fancy, but I figure there is no use in running another service if I don't ahve to.  At the moment I only have my power button set to work in the event that there are no users logged in, though there are a few other variables you can use.

I actually switched all this stuff off. I use laptop-mode-tools and I'm pretty sure that needs acpid. Or, at least, it needs it to work correctly. I have stuff switched when I go from battery to AC and back and laptop-mode-tools/acpid etc. handles that nicely. For example, I have bluetooth off, wifi in a lower power mode, lower screen brightness and various other things when I'm running on battery. laptop-mode-tools means I don't have to think about that stuff every time I plug or unplug from AC.

I will try to keep up with your "systemd flow of consciousness" seen above to see if I can answer any more questions.

Thank you smile.

I think you are a very active and respectable member of the community, and am happy to throw ideas back and forth with you.

Active? Maybe. Respectable? Never!


How To Ask Questions The Smart Way | Help Vampires

Arch Linux | x86_64 | GPT | EFI boot | grub2 | systemd | LVM2 on LUKS
Lenovo x121e | Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz GenuineIntel | Intel Centrino Wireless-N 1000 | US keyboard with Euro | 320G 7200 RPM Seagate HDD

Offline

#17 2012-08-28 01:36:35

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 5,663

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

So I know that I need to mask arch-daemons.target and I understand I'm meant to link it to /dev/null. So I created a symlink at /etc/systemd/system/arch-daemons.target. However, this doesn't work although it does confuse systemd after boot. (It thinks the file has changed on disk when it hasn't.) I guess this is because the targets in multi-user.target.wants under /usr/lib are relative links to the files in the directory above.

So is the right thing to do to create the link in /etc/systemd/system/multi-user.target.wants/arch-daemons.target directly? I thought that I wasn't meant to write directly to that directory but to put custom stuff in the parent directory and let systemctl handle symlinks in the .wants directories themselves?


How To Ask Questions The Smart Way | Help Vampires

Arch Linux | x86_64 | GPT | EFI boot | grub2 | systemd | LVM2 on LUKS
Lenovo x121e | Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz GenuineIntel | Intel Centrino Wireless-N 1000 | US keyboard with Euro | 320G 7200 RPM Seagate HDD

Offline

#18 2012-08-28 01:40:49

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,412

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

With the syslog-ng, I think all you ahve to di is set it to listen to the journal socket rather than what it is currently set to.  I remember reading this somewhere, but can't remember where it was.  I am unsure if you would be then satisfied with the resulting format of the syslog though.  I would think that it would be the same as the regular journal interms of format.

With the alsa, the only thing aI can really think of that it would be doing is setting it one way and then racing with the otehr one to set it another.  But this is purely specualtion, so I am entirely unsure about this.  Have you tried seeing if you can modify the existing service to set it to dowhat you want it to do?

So in order to have a pure systemd setup, you have to install systemd-sysvcompat, and this package conflicts with the initscripts package.  So unless you have modified the PKGBUILD, I think you will always have a hybrid setup as long as you want to keep those options open.... actually, I just checked out what is actually in that package and it is this

curtisshima@arch64 /etc/conf.d % pacman -Ql systemd-sysvcompat
systemd-sysvcompat /etc/
systemd-sysvcompat /etc/profile.d/
systemd-sysvcompat /etc/profile.d/locale.sh
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

so I think that it is entirely possible to do without this since it simply redirects the core functions of sysv to systemctl.  So you might be on to something there.

As far as the power stuff is concerned, I just keep my laptop in a low pwer state all the time.  I really don't need all the power built into this machine.  I notice that it runs at 1.2ghz most of the time anyways, so I just figure I can manually change things if I need to.  Until I got this machine though, I was using just acpid and pm-utils.  I have actaully kept pm-utils on my computer so that I can reference the scripts for the system-sleep if I run into problems.  Then I just redirected pm-suspend etc by putting scripts in /usr/local/bin that point it to systemctl.

Offline

#19 2012-08-28 01:50:30

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,412

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

Here I just reboot so that I could show you this.

Startup finished in 1244ms (kernel) + 2909ms (initramfs) + 1883ms (userspace) = 6036ms

and my initramfs is ususally nearly a second faster... don't know what happened that time.

Offline

#20 2012-08-28 12:25:26

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 5,663

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

Thanks for all the feedback. Your boot time is quite impressive. I'm sure I could streamline mine if I wanted to - it just isn't that big a deal to me, to be honest.

I found my laptop doesn't sleep on lid close with systemd. I can get it to do this by modifying acpid's handler.sh. What I'm not sure about is how it was working with initscripts so I'm not sure whether this will create an issue. (I know systemd can handle this but it is relatively limited and I need acpid for the other stuff as far as I can tell.)

I have a bunch of changes run on switch to battery to save power - not just screen brightness and bluetooth but also affecting writes to disk, usb power and that kind of thing. I worked my way through the laptop-mode-tools configuration files, basically. But I wouldn't really want to run that way on AC! I don't change the CPU stuff - I just let the ondemand governor handle that regardless. It's all the other little tweaks which I use laptop-mode-tools/acpid for.

I think you are right about the syslog-ng. I'm hesitating to switch the config only because I still want it to run with initscripts for now.

I don't plan to keep both options. It is just a temporary thing. Once I'm reasonably happy with the setup and an emergency shell is available for systemd, I'll jump ship and remove the extra options from grub's config, tweak fstab and redirect syslog-ng. And, of course, replace initscripts with the compatibility package. Plus I want to be sure it will boot properly without rc.conf before finally ditching initscripts. As you say, my understanding is that that is more a convenience thing than anything else but it still will be nice to have.

I'm quite surprised, actually, that my laptop shut's down from KDE's poweroff dialog since it seems to be using the standard commands from initscripts. There's an awful lot I don't understand about how this stuff is working/supposed to work at this point! I do know I'm currently starting everything at least twice with systemd - first through rc.conf and second through the native units (or vice-versa). I need to figure out how to mask targets properly to fix that, I think.

The alsa thing is a bit odd. I'm really not sure what is going on with that. I can't figure out why having it muted would cause errors. I'm not sure this is systemd-specific, though. In any case, it isn't that the result is wrong - sound gets enabled but muted if it was muted at shutdown. It is just a niggling worry about the "failed" non-existent unit.


How To Ask Questions The Smart Way | Help Vampires

Arch Linux | x86_64 | GPT | EFI boot | grub2 | systemd | LVM2 on LUKS
Lenovo x121e | Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz GenuineIntel | Intel Centrino Wireless-N 1000 | US keyboard with Euro | 320G 7200 RPM Seagate HDD

Offline

#21 2012-08-28 12:43:12

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 5,663

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

So according to Arch's docs, I can prevent systemd from using rc.conf by masking the arch-daemons.target.

I found this information about masking .service units on http://0pointer.de/blog/projects/three- … f-off.html:

You can mask a service. This is like disabling a service, but on steroids. It not only makes sure that service is not started automatically anymore, but even ensures that a service cannot even be started manually anymore. This is a bit of a hidden feature in systemd, since it is not commonly useful and might be confusing the user. But here's how you do it:

$ ln -s /dev/null /etc/systemd/system/ntpd.service
$ systemctl daemon-reload

By symlinking a service file to /dev/null you tell systemd to never start the service in question and completely block its execution. Unit files stored in /etc/systemd/system override those from /lib/systemd/system that carry the same name. The former directory is administrator territory, the latter terroritory of your package manager. By installing your symlink in /etc/systemd/system/ntpd.service you hence make sure that systemd will never read the upstream shipped service file /lib/systemd/system/ntpd.service.

systemd will recognize units symlinked to /dev/null and show them as masked. If you try to start such a service manually (via systemctl start for example) this will fail with an error.

A similar trick on SysV systems does not (officially) exist. However, there are a few unofficial hacks, such as editing the init script and placing an exit 0 at the top, or removing its execution bit. However, these solutions have various drawbacks, for example they interfere with the package manager.

Masking a service is a permanent change, much like disabling a service.

However, there's obviously some different trick needed for .target units because creating the symlink in /etc/systemd/system hasn't made any difference for arch-daemons.target. That is, systemctl reports it as masked but it still runs the generator stuff on boot:

$ ls -l /etc/systemd/system/arch-daemons.target 
lrwxrwxrwx 1 root root 9 Aws  28 01:49 /etc/systemd/system/arch-daemons.target -> /dev/null

$ ls /run/systemd/generator.late/
acpid.service               cupsd.service       incrond.service       lircd.service    ntpdate.service     speechd.service
alsa.service                dbus.service        ip6tables.service     lircmd.service   partimaged.service  sshd.service
arch-daemons.target.wants/  fancontrol.service  iptables.service      mdadm.service    ppp.service         svnserve.service
avahi-daemon.service        ftpd.service        irexecd.service       monitd.service   rfkill.service      syslog-ng.service
avahi-dnsconfd.service      git-daemon.service  kdm.service           mysqld.service   rsyncd.service      wicd.service
bluetooth.service           gpm.service         krb5-kadmind.service  netfs.service    sensord.service     xinetd.service
clamav.service              healthd.service     krb5-kdc.service      network.service  sensors.service
cpupower.service            hwclock.service     krb5-kpropd.service   nscd.service     smartd.service
crond.service               ifplugd.service     laptop-mode.service   ntpd.service     snmpd.service

After doing a daemon-reload once everything is booted up, I get:

$ systemctl status arch-daemons.target
arch-daemons.target
          Loaded: masked (/dev/null)
          Active: inactive (dead)

$ systemctl status sensors
sensors.service - Legacy unit for sensors
          Loaded: loaded (/etc/rc.conf)
          Active: inactive (dead)
            Docs: man:arch-daemons(8)
          CGroup: name=systemd:/system/sensors.service

$ systemctl status alsa
alsa.service - Legacy unit for alsa
          Loaded: loaded (/etc/rc.conf)
          Active: inactive (dead)
            Docs: man:arch-daemons(8)
          CGroup: name=systemd:/system/alsa.service

But what more do I need to do to prevent the generation of the arch-daemons wrapper services in the first place?


How To Ask Questions The Smart Way | Help Vampires

Arch Linux | x86_64 | GPT | EFI boot | grub2 | systemd | LVM2 on LUKS
Lenovo x121e | Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz GenuineIntel | Intel Centrino Wireless-N 1000 | US keyboard with Euro | 320G 7200 RPM Seagate HDD

Offline

#22 2012-08-28 23:47:55

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 5,663

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

I realised there's an easier way to mask the target:

systemctl mask arch-daemons.target

However, all this does is automatically create the same symlink I'd made.

I thought this would block the creation of the legacy rc.d service wrappers but it seems it does not. I'm not sure if this is because [in descending order of probability] (a) I've screwed up; (b) I've misunderstood - it isn't meant to do that; or (c) it doesn't actually do that even though it is meant to.

At any rate, I'm still getting the full range of service files created on-the-fly under /run/systemd/generator.late. For example:

$ systemctl status alsa
alsa.service - Legacy unit for alsa
          Loaded: loaded (/etc/rc.conf)
          Active: inactive (dead)
            Docs: man:arch-daemons(8)
          CGroup: name=systemd:/system/alsa.service

$ systemctl status rfkill
rfkill.service - RFKill-Block Selected Devices
          Loaded: loaded (/usr/lib/systemd/system/rfkill.service; disabled)
          Active: inactive (dead)
          CGroup: name=systemd:/system/rfkill.service

And now I can't resume if I sleep by closing the lid... (Though I don't think this is related to systemd.)


How To Ask Questions The Smart Way | Help Vampires

Arch Linux | x86_64 | GPT | EFI boot | grub2 | systemd | LVM2 on LUKS
Lenovo x121e | Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz GenuineIntel | Intel Centrino Wireless-N 1000 | US keyboard with Euro | 320G 7200 RPM Seagate HDD

Offline

#23 2012-08-29 02:04:45

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,412

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

Sorry for not responding, got caught up with some stuff.  You know to be honest I have not seen the ned to mask anything because I am running pure systemd.  So when initscripts is taken off you no loner have the arch-daemons.* stuff.  I do like the little trick with the systemctl mask though, I was unaware of that. 

About the sleep thing, or rather resume, if you are closing the lid and using the handler script, did you insert the correct command to use systemd, namely systemctl suspend?  Because looking over what is in the sysvcompat package, it seems that is when you actually get the commands that link the standard shutdown, suspend, etc to the native systemd methods.  I don't know that it would make any difference though since using pm-suspend still works fine for me (albiet it is pretty slow).

I think that if you just enable the systemd lid handling, it wouldn't really have and adverse effects.  I assume that since you are already running systemd, letting it handle something that it is apparently already keeping track of doesn't seem like it would hurt.  I know you need acpid to run for your laptop-mode stuff, but what if you gave just that responsibility to systemd to see if it worked better for you.  Of course then commenting out whatever you ahve in your handler script to ensure you are not trying to double suspend. 

Just a thought, but I think that (not sure) syslog-ng allows you to use the config file of your choice when you start it up.  So what if you made two config files, left the default as it, but made another and then customized the syslog-ng.service file, appending the new config file to the command?  I don't have syslog-ng on my computer anymore as I rely solely on the journalctl, so I am unsure if this is *really* possible, but I kind of remember seeing an option (like maybe "-c" or "--config=") to bend it to your will a little more.

So were you able to effectively mask the target files?  I see in the above post that they are still for some reason running.  Out of curiosity, what is it about the alsa rc.d daemon that you like that systemd's service file seems to not do?  From my understanding of the way service files and rc.d scripts relate, they both ultimately end up running some form of the command in question and then forking them (usually).  So again, why not open the alsa file in rc.d and see what the command is that it uses, and then check it against the systemd one.  You could always modify the alsa-store.serivce so that it too does more of what you want.  Of course that still does not solve the problem of why in the heck it is still trying to run both at once.

Seems like you mare making progress though, I say keep chipping away at it.  One thing that I think might help you out though is if you were to take a usb flash drive, so a quick install of Arch on it with initscripts, and then load some daemons and whatnot, just a couple (namely the problem ones you have now), and then see if you can switch it fully without issue.  Then you might have a bit of confidence instilled in you that it can be done easily... or not if sh*t goes awry.  I just did it in one fell swoop because I had just set this computer up and had backups of everything that were super current, so I figured, "what the hell?"  I rather enjoy that feeling of fixing something that breaks on my system.  Someimtes not the process of fixing, but the aftermath is always satisfying.  So to me switching was just another neat project that could potentially cause severe breakage.

Offline

#24 2012-08-29 02:16:05

progandy
Member
Registered: 2012-05-17
Posts: 2,151

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

WonderWoofy wrote:

Just a thought, but I think that (not sure) syslog-ng allows you to use the config file of your choice when you start it up.  So what if you made two config files, left the default as it, but made another and then customized the syslog-ng.service file, appending the new config file to the command?  I don't have syslog-ng on my computer anymore as I rely solely on the journalctl, so I am unsure if this is *really* possible, but I kind of remember seeing an option (like maybe "-c" or "--config=") to bend it to your will a little more.

You don't need the package installed to read the manpages wink Yes, syslog-ng has an option to specify the config file. http://manned.org/syslog-ng

Offline

#25 2012-08-29 02:18:26

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,412

Re: Replicating /etc/rc.d/* and pm-utils functionality with systemd

This is true, but my responses to this thread have been mostly just been a stream of thoughts as I read cfr's posts.  So I figure it is something that he could probably check out.

Edit: also, I apparently did remember correctly and it is --cfgfile (though wrong about the flags)

Last edited by WonderWoofy (2012-08-29 02:19:28)

Offline

Board footer

Powered by FluxBB