systemd: Yet Another Init Replacement

snufkin · 2012-05-04 15:07:23

When writing a .service file, is there any way to include variables set in another file? For instance, if /etc/conf.d/foo contains the following

FOO="bar"

When using an old init script, I would begin the script with . /etc/conf.d/foo. Is it ok to do this in a .service file too, or would that be considered bad manner for some reason?

65kid · 2012-05-04 15:12:33

snufkin wrote:

When writing a .service file, is there any way to include variables set in another file? For instance, if /etc/conf.d/foo contains the following
FOO="bar"
When using an old init script, I would begin the script with . /etc/conf.d/foo. Is it ok to do this in a .service file too, or would that be considered bad manner for some reason?

Have a look at EnvironmentFile= in "man 5 systemd.exec".

snufkin · 2012-05-04 22:50:42

Thanks, that works just fine! If only I could say that about the script in general.

Here's my /etc/systemd/system/cjdns.service:

[Unit]
Description=CJDNS

[Service]
EnvironmentFile=/etc/conf.d/cjdns
User=${CJDNS_USER}
PermissionsStartOnly=true
ExecStart=/usr/bin/cjdroute < ${CJDNS_CONFIG}
ExecStartPre=/usr/bin/cjdroute --getcmds < ${CJDNS_CONFIG} | /bin/bash

[Install]
WantedBy=multi-user.target

This results in Job failed. See system journal and 'systemctl status' for details. systemctl status cjdns.service gives me the following:

cjdns.service - CJDNS
	  Loaded: loaded (/etc/systemd/system/cjdns.service; disabled)
	  Active: failed (Result: exit-code) since Sat, 05 May 2012 02:43:29 +0200; 4s ago
	 Process: 1886 ExecStartPre=/usr/bin/cjdroute --getcmds < ${CJDNS_CONFIG} | /bin/bash (code=exited, status=217/USER)
	Main PID: 1826 (code=exited, status=255)
	  CGroup: name=systemd:/system/cjdns.service

Can anyone tell me why it's not working? I want the ExecStartPre to run with root privileges, and then I want ExecStart to run as the user specified in the env var file. Should be simple, but I can't figure out what's wrong.

Last edited by snufkin (2012-05-04 22:52:27)

tomegun · 2012-05-04 23:08:55

snufkin: ExecStart= lines are not bash. you can not use pipes or redirection. If you want that you must create a bash script and call that from ExecStart.

snufkin · 2012-05-04 23:12:42

Yeah, that's what I thought, just wanted to get it confirmed. I was hoping to avoid bash scripts, but it seems like I don't have a choice.

blackout23 · 2012-05-05 19:58:20

Anyone has an idea what this means?

[tim@archhost ~]$ sudo systemctl enable acpid.service
Warning: unit files do not carry install information. No operation executed.

litemotiv · 2012-05-05 20:00:14

blackout23 wrote:

Anyone has an idea what this means?

[tim@archhost ~]$ sudo systemctl enable acpid.service
Warning: unit files do not carry install information. No operation executed.

https://bbs.archlinux.org/viewtopic.php … 1#p1068171

blackout23 · 2012-05-05 20:32:51

litemotiv wrote:

blackout23 wrote:
Anyone has an idea what this means?
[tim@archhost ~]$ sudo systemctl enable acpid.service
Warning: unit files do not carry install information. No operation executed.
https://bbs.archlinux.org/viewtopic.php … 1#p1068171

Haha thank you!

Leonid.I · 2012-05-07 19:29:16

tomegun wrote:

@Leonid: so it seems pretty clear. consolekit creates a new session when you enter xfce, but according to systemd you still only have one session (and my guess is that if you now do "systemd-loginctl session-status <your session id>" it is no longer active). A login manager would sort this out for you (until systemd has proper support for this kind of stuff (which, by the way, i believe will be awesome!)).

Yes, you are right -- the original systemd session is indeed inactive. I'm going to stick with gdm for now.

graysky · 2012-05-10 16:02:00

deleted

Last edited by graysky (2012-05-11 20:42:13)

slint · 2012-05-12 21:22:24

So if I need avahi, do I have to activate avahi-daemon.socket or avahi-daemon.service?

litemotiv · 2012-05-12 21:46:02

Does anyone else have problems with blacklisting with the current systemd 44-7? I am blacklisting bcma for my wireless but this currently fails (module gets loaded).

MOPSTER · 2012-05-12 21:58:07

blackout23 wrote:

Anyone has an idea what this means?

[tim@archhost ~]$ sudo systemctl enable acpid.service
Warning: unit files do not carry install information. No operation executed.

acpid.service doesn't provide an [Install] section so systemd doesn't know where to symlink it.

falconindy · 2012-05-12 23:05:23

litemotiv wrote:

Does anyone else have problems with blacklisting with the current systemd 44-7? I am blacklisting bcma for my wireless but this currently fails (module gets loaded).

Probably because bcma is loaded as a dependency for other modules. blacklist rules don't effect deps.

brcmsmac                   /lib/modules/3.3.5-1-ARCH/kernel/drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.ko.gz
├─mac80211                 /lib/modules/3.3.5-1-ARCH/kernel/net/mac80211/mac80211.ko.gz                           
│ └─cfg80211               /lib/modules/3.3.5-1-ARCH/kernel/net/wireless/cfg80211.ko.gz                           
│   └─rfkill               /lib/modules/3.3.5-1-ARCH/kernel/net/rfkill/rfkill.ko.gz                               
├─brcmutil                 /lib/modules/3.3.5-1-ARCH/kernel/drivers/net/wireless/brcm80211/brcmutil/brcmutil.ko.gz
├─cfg80211                 /lib/modules/3.3.5-1-ARCH/kernel/net/wireless/cfg80211.ko.gz
│ └─rfkill                 /lib/modules/3.3.5-1-ARCH/kernel/net/rfkill/rfkill.ko.gz
├─cordic                   /lib/modules/3.3.5-1-ARCH/kernel/lib/cordic.ko.gz
├─bcma                     /lib/modules/3.3.5-1-ARCH/kernel/drivers/bcma/bcma.ko.gz                               
└─crc8                     /lib/modules/3.3.5-1-ARCH/kernel/lib/crc8.ko.gz

Last edited by falconindy (2012-05-12 23:07:14)

litemotiv · 2012-05-13 09:00:04

falconindy wrote:

Probably because bcma is loaded as a dependency for other modules. blacklist rules don't effect deps.

brcmsmac                   /lib/modules/3.3.5-1-ARCH/kernel/drivers/net/wireless/brcm80211/brcmsmac/brcmsmac.ko.gz
├─mac80211                 /lib/modules/3.3.5-1-ARCH/kernel/net/mac80211/mac80211.ko.gz                           
│ └─cfg80211               /lib/modules/3.3.5-1-ARCH/kernel/net/wireless/cfg80211.ko.gz                           
│   └─rfkill               /lib/modules/3.3.5-1-ARCH/kernel/net/rfkill/rfkill.ko.gz                               
├─brcmutil                 /lib/modules/3.3.5-1-ARCH/kernel/drivers/net/wireless/brcm80211/brcmutil/brcmutil.ko.gz
├─cfg80211                 /lib/modules/3.3.5-1-ARCH/kernel/net/wireless/cfg80211.ko.gz
│ └─rfkill                 /lib/modules/3.3.5-1-ARCH/kernel/net/rfkill/rfkill.ko.gz
├─cordic                   /lib/modules/3.3.5-1-ARCH/kernel/lib/cordic.ko.gz
├─bcma                     /lib/modules/3.3.5-1-ARCH/kernel/drivers/bcma/bcma.ko.gz                               
└─crc8                     /lib/modules/3.3.5-1-ARCH/kernel/lib/crc8.ko.gz

How would i work around this? I need brcmsmac but when bcma is loaded that fails. bcma is loaded first though:

$ dmesg | grep bcma

[6.388214] bcma-pci-bridge 0000:02:00.0: enabling device (0000 -> 0002)
[6.388344] bcma: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x22, class 0x0)
[6.388374] bcma: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x17, class 0x0)
[6.388437] bcma: Core 2 found: PCIe (manuf 0x4BF, id 0x820, rev 0x0F, class 0x0)
[6.455310] bcma: Unsupported SPROM revision: 255
[6.455369] bcma: No SPROM available
[6.455434] bcma: Bus registered
[6.511168] brcmsmac bcma0:0: mfg 4bf core 812 rev 23 class 0 irq 17
[6.718270] brcmsmac: brcms_bcma_probe: brcms_attach failed!

So at the moment i need to manually rmmod both, then modprobe brcmsmac again to get wlan0.

Last edited by litemotiv (2012-05-13 09:02:08)

Zom · 2012-05-13 10:14:15

litemotiv wrote:

How would i work around this? I need brcmsmac but when bcma is loaded that fails.

The part about using install MODULENAME /bin/false should work, https://wiki.archlinux.org/index.php/Mo … acklisting

litemotiv · 2012-05-13 10:56:06

Zom wrote:

The part about using install MODULENAME /bin/false should work, https://wiki.archlinux.org/index.php/Mo … acklisting

Thanks Zom, this looks like a case of RTFW.

65kid · 2012-05-14 13:08:34

http://freedesktop.org/wiki/Software/sy … imizations

Consider removing cron from your system and use systemd timer units instead. Timer units currently have no support for calendar times (i.e. cannot be used to spawn things "at 6 am every monday", but can do "run this every 7 days"), but for the usual /etc/cron.daily/, /etc/cron.weekly/, ... should be good enough, if the time of day of the execution doesn't matter (just add four small service and timer units for supporting these dirs. Eventually we might support these out of the box, but until then, just write your own scriplets for this).

Challenge accepted!

/etc/systemd/system/timer-daily.target

[Unit]
Description=Daily Timer Target
StopWhenUnneeded=yes

/etc/systemd/system/timer-daily.timer

[Unit]
Description=Daily Timer

[Timer]
OnBootSec=10min
OnUnitActiveSec=1d
Unit=timer-daily.target

[Install]
WantedBy=basic.target

/etc/systemd/system/timer-daily.target.wants/man-db-update.service

[Unit]
Description=Update man-db

[Service]
Nice=19
IOSchedulingClass=2
IOSchedulingPriority=7
ExecStart=/usr/bin/mandb --quiet

/etc/systemd/system/timer-daily.target.wants/mlocate-update.service

[Unit]
Description=Update mlocate database

[Service]
Nice=19
IOSchedulingClass=2
IOSchedulingPriority=7
ExecStart=/usr/bin/updatedb

/etc/systemd/system/timer-daily.target.wants/verify-shadow.service

[Unit]
Description=Verify integrity of password and group files

[Service]
Type=oneshot
ExecStart=/usr/sbin/pwck -r
ExecStart=/usr/sbin/grpck -r

# systemctl daemon-reload
# systemctl enable timer-daily.timer
# systemctl start timer-daily.timer
# pacman -R cronie

yes, that's a lot of stuff. but consider that the service files replace the (more complex) shell scripts in /etc/cron.daily/ and timer-daily.target/timer will not be neccessary when systemd supports something equivalent out of the box.
You would obviously have to write your own stuff for now if you have other scripts in /etc/cron.daily or need /etc/cron.weekly etc, but you should get the idea.

litemotiv · 2012-05-15 19:28:17

litemotiv wrote:

Zom wrote:
The part about using install MODULENAME /bin/false should work, https://wiki.archlinux.org/index.php/Mo … acklisting
Thanks Zom, this looks like a case of RTFW.

Hmm this is not working for me unfortunately. I'm not sure what the problem is; not blacklisting anything doesn't work, blacklisting or 'false loading' bcma doesn't either. It's not a systemd issue though, so i won't pollute the thread with it any further.

Runiq · 2012-05-23 13:29:53

65kid wrote:

I am an awesome ninja

Damn you, 65kid! >:(

Seriously though, thanks. Saves me the trouble of converting all that. Does it work all right?

65kid · 2012-05-23 14:40:18

Runiq wrote:

65kid wrote:
I am an awesome ninja

Hey, I never said that!

Runiq wrote:

Damn you, 65kid! >:(
Seriously though, thanks. Saves me the trouble of converting all that. Does it work all right?

Works fine here, yes. although verify-shadow.service only makes sense if you actually check if the service has failed (systemctl --failed). to be honest, I'm not sure how this was handled with cron. did it just write an error to the log? I don't know, grpck/pwck never actually failed on my system.

Cdh · 2012-05-27 21:17:20

I hope this is not too off topic here:
If you upgrade to udev/systemd from testing and try to use lightdm (and are as unlucky as I am) you're gonna have a bad time.

After the update I cleaned up quite some broken symlinks that were around from earlier versions (avahi, sshd, ntpd) and re-enabled those services. I'm not sure that it's ok that with time it leaves so many broken symlinks in /etc/systemd/system/...

Then I had trouble starting lightdm. I tried both lightdm-bzw and lightdm with completely deleting any config from /etc/lightdm and /var/lib/**/*lightdm* and tried around a bit but I couldn't get it to start.

May 27 22:54:14 chrisl sudo[20252]: chris : TTY=tty2 ; PWD=/home/chris ; USER=root ; COMMAND=/usr/bin/systemctl start lightdm.service
May 27 22:54:14 chrisl sudo[20252]: pam_unix(sudo:session): session opened for user root by chris(uid=0)
May 27 22:54:14 chrisl systemd[1]: Accepted connection on private bus.
May 27 22:54:14 chrisl systemd[1]: Got D-Bus request: org.freedesktop.systemd1.Manager.StartUnit() on /org/freedesktop/systemd1
May 27 22:54:14 chrisl systemd[1]: Trying to enqueue job lightdm.service/start/replace
May 27 22:54:14 chrisl systemd[1]: Installed new job lightdm.service/start as 907
May 27 22:54:14 chrisl systemd[1]: Installed new job dev-tty7.device/start as 908
May 27 22:54:14 chrisl systemd[1]: Enqueued job lightdm.service/start as 907
May 27 22:54:14 chrisl systemd[1]: Got D-Bus request: org.freedesktop.systemd1.Manager.GetUnit() on /org/freedesktop/systemd1
May 27 22:54:14 chrisl systemd[1]: Got D-Bus request: org.freedesktop.DBus.Properties.Get() on /org/freedesktop/systemd1/unit/lightdm_2eservice
May 27 22:55:44 chrisl systemd[1]: Job dev-tty7.device/start timed out.
May 27 22:55:44 chrisl systemd[1]: Job dev-tty7.device/start finished, result=timeout
May 27 22:55:44 chrisl systemd[1]: Job lightdm.service/start finished, result=dependency
May 27 22:55:44 chrisl systemd[1]: Job lightdm.service/start failed with result 'dependency'.
May 27 22:55:44 chrisl systemd[1]: Job dev-tty7.device/start failed with result 'timeout'.
May 27 22:55:44 chrisl systemd[1]: Running GC...
May 27 22:55:44 chrisl systemd[1]: Collecting lighdm.service
May 27 22:55:44 chrisl systemd[1]: Got D-Bus request: org.freedesktop.DBus.Local.Disconnected() on /org/freedesktop/DBus/Local

It would be really great if there was an easy way to actually find out what the actual dependency problem is...

In the meantime I use kdm again which kind of works (came up "inactive (dead)" after boot but starting manually with systemctl start kdm.service works).

Is there a reason why systemd and lightdm still fail at basic tasks? (I know, when using testing I shouldn't complain )

tomegun · 2012-05-27 22:22:11

Cdh wrote:

May 27 22:55:44 chrisl systemd[1]: Job dev-tty7.device/start timed out.
May 27 22:55:44 chrisl systemd[1]: Job dev-tty7.device/start finished, result=timeout
May 27 22:55:44 chrisl systemd[1]: Job lightdm.service/start finished, result=dependency
May 27 22:55:44 chrisl systemd[1]: Job lightdm.service/start failed with result 'dependency'.

It would be really great if there was an easy way to actually find out what the actual dependency problem is...

It tells you :-) The dependency tty-7 timed out. This should be fixed in the next systemd-arch-units package, if not, you just need to remove all references to dev-tty.device from all your service files. The reason is that tty devices are always available, so systemd no longer tracks them.

Is there a reason why systemd and lightdm still fail at basic tasks? (I know, when using testing I shouldn't complain )

I believe this particular problem has been fixed, but in general I assume the problem with lightdm is that it might not be tested much yet with systemd (being an ubuntu project and all).

Cdh · 2012-05-27 22:36:24

tomegun wrote:

It tells you :-) The dependency tty-7 timed out.

If that's it, good. I somehow assumed it would be some problem while resolving dependencies like circles in the dependency graph.

tomegun wrote:

This should be fixed in the next systemd-arch-units package, if not, you just need to remove all references to dev-tty.device from all your service files. The reason is that tty devices are always available, so systemd no longer tracks them.

Great! So, nothing to see here, move along.

The lightdm service file is in fact the only one that has a reference to dev-tty* and that's why other display managers work.

tomegun wrote:

I believe this particular problem has been fixed, but in general I assume the problem with lightdm is that it might not be tested much yet with systemd (being an ubuntu project and all).

That came from a misconception of me that somehow Lennart was involved with lightdm. No he isn't. So I better stop tiredly talking before I embarass myself further.

boast · 2012-05-28 00:29:54

I cannot start my system with my usb mouse connected. It stops with "failed to start /sys/bus/usb/drivers." I have to disconnect it and reconnect it after I'm finished booting.

Last edited by boast (2012-05-28 00:46:35)

Arch Linux

#1376 2012-05-04 15:07:23

Re: systemd: Yet Another Init Replacement

#1377 2012-05-04 15:12:33

Re: systemd: Yet Another Init Replacement

#1378 2012-05-04 22:50:42

Re: systemd: Yet Another Init Replacement

#1379 2012-05-04 23:08:55

Re: systemd: Yet Another Init Replacement

#1380 2012-05-04 23:12:42

Re: systemd: Yet Another Init Replacement

#1381 2012-05-05 19:58:20

Re: systemd: Yet Another Init Replacement

#1382 2012-05-05 20:00:14

Re: systemd: Yet Another Init Replacement

#1383 2012-05-05 20:32:51

Re: systemd: Yet Another Init Replacement

#1384 2012-05-07 19:29:16

Re: systemd: Yet Another Init Replacement

#1385 2012-05-10 16:02:00

Re: systemd: Yet Another Init Replacement

#1386 2012-05-12 21:22:24

Re: systemd: Yet Another Init Replacement

#1387 2012-05-12 21:46:02

Re: systemd: Yet Another Init Replacement

#1388 2012-05-12 21:58:07

Re: systemd: Yet Another Init Replacement

#1389 2012-05-12 23:05:23

Re: systemd: Yet Another Init Replacement

#1390 2012-05-13 09:00:04

Re: systemd: Yet Another Init Replacement

#1391 2012-05-13 10:14:15

Re: systemd: Yet Another Init Replacement

#1392 2012-05-13 10:56:06

Re: systemd: Yet Another Init Replacement

#1393 2012-05-14 13:08:34

Re: systemd: Yet Another Init Replacement

#1394 2012-05-15 19:28:17

Re: systemd: Yet Another Init Replacement

#1395 2012-05-23 13:29:53

Re: systemd: Yet Another Init Replacement

#1396 2012-05-23 14:40:18

Re: systemd: Yet Another Init Replacement

#1397 2012-05-27 21:17:20

Re: systemd: Yet Another Init Replacement

#1398 2012-05-27 22:22:11

Re: systemd: Yet Another Init Replacement

#1399 2012-05-27 22:36:24

Re: systemd: Yet Another Init Replacement

#1400 2012-05-28 00:29:54

Re: systemd: Yet Another Init Replacement

Board footer