Systemd service failing on boot

Hello, im new to Arch and systemd
When I boot my computer the sabnzbd service fails to start, but if i start it manually afterwards it works fine.
I can make it work by adding a 'sleep 10' to the .service file but that seems like a hack and I'd like to learn the correct way.
It seems as though the sabnzbd.service is starting before the /run tmpfs partition has been mounted but I dont know. 
I'm hoping someone smarter than me knows the answer to this
Thanks
Dave
Below is the messages.log
Oct 24 19:58:35 winter systemd[1]: PID file /run/sabnzbd/sabnzbd-8080.pid not readable (yet?) after start.
Oct 24 19:58:36 winter systemd[1]: sabnzbd.service never wrote its PID file. Failing.
Oct 24 19:58:36 winter systemd[1]: Unit sabnzbd.service entered failed state.
Oct 24 19:58:36 winter systemd[1]: Starting Multi-User.
Oct 24 19:58:36 winter systemd[1]: Reached target Multi-User.
Oct 24 19:58:36 winter systemd[1]: Starting Graphical Interface.
Oct 24 19:58:36 winter systemd[1]: Reached target Graphical Interface.
Oct 24 19:58:36 winter systemd[1]: Starting Update UTMP about System Runlevel Changes...
Oct 24 19:58:36 winter systemd[1]: Started Update UTMP about System Runlevel Changes.
Oct 24 19:58:36 winter systemd[1]: Startup finished in 4s 330ms 255us (kernel) + 8s 66ms 514us (userspace) = 12s 396ms 769us.
Oct 24 19:58:36 winter ifplugd[282]: Executing '/etc/ifplugd/netcfg.action eth0 up'.
Oct 24 19:58:36 winter ifplugd[282]: client: up
Oct 24 19:58:36 winter ifplugd[282]: client: loading ethernet-static
Oct 24 19:58:36 winter ifplugd[282]: client: :: ethernet-static up [done]
Oct 24 19:58:36 winter ifplugd[282]: Program executed successfully.
sabnzbd.service:
[Unit]
Description=SABnzbd binary newsreader
After=network.target
[Service]
EnvironmentFile=/etc/conf.d/sabnzbd_systemd
#ExecStartPre=/usr/bin/sleep 10
ExecStart=/bin/sh/ -c "python2 ${SABNZBD_DIR}/SABnzbd.py ${SABNZBD_ARGS} --pid /run/sabnzbd"
ExecStop=/usr/bin/curl -f "${SABNZBD_PROTOCOL}://${SABNZBD_USPW}${SABNZBD_IP}:${SABNZBD_PORT}/sabnzbd/api?mode=shutdown&apikey=${SABNZBD_KEY}"
Type=forking
PIDFile=/run/sabnzbd/sabnzbd-8080.pid
User=sabnzbd
Group=sabnzbd
[Install]
WantedBy=multi-user.target

For diagnostics try:
# systemctl status sabnzbd.service

Similar Messages

  • Systemd-logind fails at boot

    Hello,
    systemd-logind.service fails at boot.
    I get this status:
    [root /home/bas] # systemctl status systemd-logind.service
    ● systemd-logind.service - Login Service
    Loaded: loaded (/usr/lib/systemd/system/systemd-logind.service; static)
    Active: failed (Result: start-limit) since Thu 2014-11-27 15:07:45 CET; 14s ago
    Docs: man:systemd-logind.service(8)
    man:logind.conf(5)
    http://www.freedesktop.org/wiki/Software/systemd/logind
    http://www.freedesktop.org/wiki/Software/systemd/multiseat
    Process: 5742 ExecStart=/usr/lib/systemd/systemd-logind (code=exited, status=1/FAILURE)
    Main PID: 5742 (code=exited, status=1/FAILURE)
    Status: "Shutting down..."
    Nov 27 15:07:45 bs2 systemd[1]: Failed to start Login Service.
    Nov 27 15:07:45 bs2 systemd[1]: Unit systemd-logind.service entered failed state.
    Nov 27 15:07:45 bs2 systemd[1]: systemd-logind.service failed.
    Nov 27 15:07:45 bs2 systemd[1]: start request repeated too quickly for systemd-logind.service
    Nov 27 15:07:45 bs2 systemd[1]: Failed to start Login Service.
    Nov 27 15:07:45 bs2 systemd[1]: Unit systemd-logind.service entered failed state.
    Nov 27 15:07:45 bs2 systemd[1]: systemd-logind.service failed.
    I don't know where to go from here.. Any help would be very appreciated. Thank you!
    bas

    bump... Do you need more information? I did not post more because I did not know what. Also, I searched in the forum and on the web but I could not resolve it...

  • [SOLVED] systemd : services failing to start on boot

    I have removed sysvinit completely as per the systemd wiki pages.
    I don't usually re-boot very often so I'm not sure exactly when the problem started.
    I only noticed this problem about 4 or 5 days ago.
    But now whenever I reboot my machine 2 services fail consistently.
    adsl.service
    colord.service
    They both start flawlessly once I can log in at a console.
    I'm using kde and in the last couple of days, while trying to fix my problem, the kdm service has failed to start a couple of times too - saying there is no X server.
    Before switching to systemd I never had any of these problems using the old rc.conf method. My DAEMONS array had the adsl service start after the network service.
    I need some help and advice to find out what is causing the problem and how to fix it.
    Last edited by bhrgunatha (2012-10-25 05:44:22)

    Thanks. That seems plausible. So I've been snooping at the journal.
    journalctl -ab
    Oct 25 17:06:13 starch systemd[1]: Started Trigger Flushing of Journal to Persistent Storage.
    Oct 25 17:06:14 starch systemd[1]: Started Recreate Volatile Files and Directories.
    Oct 25 17:06:14 starch systemd[1]: Starting System Initialization.
    Oct 25 17:06:14 starch systemd[1]: Reached target System Initialization.
    Oct 25 17:06:14 starch systemd[1]: Starting CUPS Printing Service Sockets.
    Oct 25 17:06:14 starch systemd[1]: Listening on CUPS Printing Service Sockets.
    Oct 25 17:06:14 starch systemd[1]: Starting Console System Startup Logging...
    Oct 25 17:06:14 starch systemd[1]: Starting Restore Sound Card State...
    Oct 25 17:06:14 starch systemd[1]: Starting CUPS Printer Service Spool.
    Oct 25 17:06:14 starch systemd[1]: Started CUPS Printer Service Spool.
    Oct 25 17:06:14 starch systemd[1]: Starting D-Bus System Message Bus Socket.
    Oct 25 17:06:16 starch ntpd[381]: ntpd [email protected] Tue Aug 21 15:06:24 UTC 2012 (1)
    Oct 25 17:06:16 starch ntpd[413]: proto: precision = 0.156 usec
    Oct 25 17:06:17 starch ntpd[413]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
    Oct 25 17:06:17 starch ntpd[413]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
    Oct 25 17:06:18 starch ntpd[413]: Listen and drop on 1 v6wildcard :: UDP 123
    Oct 25 17:06:18 starch ntpd[413]: Listen normally on 2 lo 127.0.0.1 UDP 123
    Oct 25 17:06:18 starch ntpd[413]: Listen normally on 3 lo ::1 UDP 123
    Oct 25 17:06:18 starch ntpd[413]: peers refreshed
    Oct 25 17:06:18 starch ntpd[413]: Listening on routing socket on fd #20 for interface updates
    Oct 25 17:06:18 starch dbus[384]: [system] Activating systemd to hand-off: service name='org.freedesktop.ColorManager' unit='colord.service'
    Oct 25 17:06:18 starch dbus[384]: [system] Successfully activated service 'org.freedesktop.systemd1'
    Oct 25 17:07:03 starch dbus[384]: [system] Successfully activated service 'org.freedesktop.ColorManager'
    Oct 25 17:07:03 starch dbus[384]: [system] Activating via systemd: service name='org.freedesktop.ColorManager' unit='colord.service'
    Oct 25 17:07:03 starch dbus[384]: [system] Successfully activated service 'org.freedesktop.ColorManager'
    Oct 25 17:07:04 starch kernel: r8169 0000:02:00.0: eth0: link down
    Oct 25 17:07:03 starch systemd[1]: Starting Manage, Install and Generate Color Profiles...
    Oct 25 17:07:03 starch systemd[1]: Started Manage, Install and Generate Color Profiles.
    Oct 25 17:07:03 starch systemd[1]: colord.service: main process exited, code=killed, status=6
    Oct 25 17:07:03 starch systemd[1]: Unit colord.service entered failed state.
    Oct 25 17:07:04 starch kernel: r8169 0000:02:00.0: eth0: link down
    Oct 25 17:07:04 starch kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
    Oct 25 17:07:04 starch kernel: PPP generic driver version 2.4.2
    Oct 25 17:07:04 starch cupsd[380]: Unknown directive DefaultAuthType on line 26.
    Oct 25 17:07:04 starch kernel: r8169 0000:02:00.0: eth0: link up
    Oct 25 17:07:04 starch kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
    Oct 25 17:07:04 starch pppoe-start[382]: TIMED OUT
    Oct 25 17:07:04 starch kernel: NET: Registered protocol family 24
    Oct 25 17:07:04 starch pppoe-start[382]: /usr/sbin/pppoe-start: line 193: 394 Terminated $CONNECT "$@" > /dev/null 2>&1
    That seems to confirm your theory.
    eth0 link is not up when attempting to start colord and adsl
    So the $64,000 question:
    How do I defer them until eth0 is ready?
    Or how can I force the eth0 link to be up before colord or adsl try to use it?
    Last edited by bhrgunatha (2012-10-25 01:33:36)

  • Systemd dhcpcd service failing on boot

    Hi folks,
    I'm trying to convert my workstation to "pure" systemd configuration (no initscripts-systemd):
    [csingley@quadrupel ~]$ pacman -Qs systemd
    local/libsystemd 185-3
    systemd client libraries
    local/systemd 185-3
    system and service manager
    local/systemd-arch-units 20120612-5
    Arch specific Systemd unit files
    local/systemd-sysvcompat 185-3
    sysvinit compat for systemd
    local/systemd-tools 185-3
    standalone tools from systemd
    Per the instructions on the wiki, I enabled [email protected], but the service fails to start upon boot.
    [root@quadrupel csingley]# systemctl status [email protected]
    [email protected] - dhcpcd on eth0
    Loaded: loaded (/usr/lib/systemd/system/[email protected]; enabled)
    Active: failed (Result: exit-code) since Thu, 28 Jun 2012 12:36:16 -0500; 39s ago
    Process: 299 ExecStart=/sbin/dhcpcd -A -q -w %I (code=exited, status=1/FAILURE)
    CGroup: name=systemd:/system/[email protected]/eth0
    However, I can start the service manually after the boot process is complete:
    [root@quadrupel csingley]# systemctl start [email protected]
    [root@quadrupel csingley]#
    Presumably not all dependencies have been satisfied when systemd tries to run dhcpcd during boot.
    I'm very new to systemd; any tips for troubleshooting this issue?
    TIA

    dj-x-cess wrote:
    I have the same problem.
    It seems, at least for my machine, dhcpcd starts before eth0 gets initialized on boot time:
    Sep 05 07:38:39 vostro dhcpcd[180]: version 5.6.0 starting
    Sep 05 07:38:39 vostro dhcpcd[180]: eth0: interface not found or invalid
    Sep 05 07:38:39 vostro kernel: r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
    Sep 05 07:38:39 vostro kernel: r8169 0000:13:00.0: irq 47 for MSI/MSI-X
    Sep 05 07:38:39 vostro kernel: r8169 0000:13:00.0: eth0: RTL8168d/8111d at 0xf9c00000, a4:ba:db:a6:a6:33, XID 083000c0 IRQ 47
    Sep 05 07:38:39 vostro kernel: r8169 0000:13:00.0: eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
    Yes. Same thing here with the latest install. I put "tg3" in /etc/modules-load.d/tigon.conf. Guess it loads it sooner then and now it gets an IP. Couldn't you make dhcpcd wait for eth0 to come up? It looks important, I mean dhcp should work I'm a newbie with Arch, installed it for the first time.
    Here are my logs before the fix (I was looking in /var/log/, but then I found out that there is a journalctl command):
    Nov 14 15:33:40 neimastina dhcpcd[176]: version 5.6.2 starting
    Nov 14 15:33:40 neimastina dhcpcd[176]: eth0: interface not found or invalid
    Nov 14 15:33:44 neimastina systemd[1]: [email protected]: control process exited, code=exited status=1
    Nov 14 15:33:45 neimastina kernel: EDAC MC: Ver: 3.0.0
    Nov 14 15:33:45 neimastina kernel: wmi: Mapper loaded
    Nov 14 15:33:45 neimastina kernel: iTCO_vendor_support: vendor-support=0
    Nov 14 15:33:45 neimastina kernel: tg3.c:v3.124 (March 21, 2012)
    Nov 14 15:33:45 neimastina kernel: EDAC MC0: Giving out device to 'x38_edac' 'x38': DEV 0000:00:00.0
    Nov 14 15:33:45 neimastina kernel: tg3 0000:34:00.0: eth0: Tigon3 [partno(BCM95751A519FLP) rev 4201] (PCI Express) MAC address 00:10:18:53:12:b7
    Nov 14 15:33:45 neimastina kernel: tg3 0000:34:00.0: eth0: attached PHY is 5750 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
    Nov 14 15:33:45 neimastina kernel: tg3 0000:34:00.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
    Nov 14 15:33:45 neimastina kernel: tg3 0000:34:00.0: eth0: dma_rwctrl[76180000] dma_mask[64-bit]
    Nov 14 15:33:45 neimastina kernel: gpio_ich: GPIO from 195 to 255 on gpio_ich

  • Systemd.timesyncd fails on boot [Solved]

    Upgraded systemd to 217-1 and now each boot sees timesyncd fail:
    ● systemd-timesyncd.service - Network Time Synchronization
    Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled)
    Active: failed (Result: start-limit) since Fri 2014-10-31 10:25:59 NZDT; 5min ago
    Docs: man:systemd-timesyncd.service(8)
    Process: 303 ExecStart=/usr/lib/systemd/systemd-timesyncd (code=exited, status=1/FAILURE)
    Main PID: 303 (code=exited, status=1/FAILURE)
    Status: "Shutting down..."
    Oct 31 10:25:59 Shiv systemd[1]: Failed to start Network Time Synchronization.
    Oct 31 10:25:59 Shiv systemd[1]: Unit systemd-timesyncd.service entered failed state.
    Oct 31 10:25:59 Shiv systemd[1]: systemd-timesyncd.service failed.
    Oct 31 10:25:59 Shiv systemd[1]: start request repeated too quickly for systemd-timesyncd.service
    Oct 31 10:25:59 Shiv systemd[1]: Failed to start Network Time Synchronization.
    Oct 31 10:25:59 Shiv systemd[1]: Unit systemd-timesyncd.service entered failed state.
    Oct 31 10:25:59 Shiv systemd[1]: systemd-timesyncd.service failed.
    Once I log in, I am able to restart the service without any complaint.
    Anyone else seeing this?
    # edit: perhaps related to this fixed(?) bug: http://lists.freedesktop.org/archives/s … 03199.html

    tl;dr answer:
    # sed -i 's/ remote-fs.target$//' /usr/lib/systemd/system/systemd-journal-flush.service
    Long answer:
    In systemd 217 a few changes were made with regard to ordering of early boot units, resulting in certain setups which used to work with systemd 216 to make problems with systemd 217. The fix above was also applied in systemd upstream by this commit:
    commit 919699ec301ea507edce4a619141ed22e789ac0d
    Author: Lennart Poettering <[email protected]>
    Date: Fri Oct 31 16:22:36 2014 +0100
    units: don't order journal flushing afte remote-fs.target
    Instead, only depend on the actual file systems we need.
    This should solve dep loops on setups where remote-fs.target is moved
    into late boot.
    For example, in my case, connman.service explicitly requests to be ordered before remote-fs.target, leading to all kinds of fun:
    systemd[1]: Found ordering cycle on basic.target/start
    systemd[1]: Found dependency on sysinit.target/start
    systemd[1]: Found dependency on systemd-tmpfiles-setup.service/start
    systemd[1]: Found dependency on systemd-journal-flush.service/start
    systemd[1]: Found dependency on remote-fs.target/start
    systemd[1]: Found dependency on connman.service/start
    systemd[1]: Found dependency on basic.target/start
    systemd[1]: Breaking ordering cycle by deleting job systemd-tmpfiles-setup.service/start
    systemd-timesyncd[201]: Failed to allocate manager: No such file or directory
    systemd[1]: systemd-timesyncd.service: main process exited, code=exited, status=1/FAILURE
    systemd[1]: Failed to start Network Time Synchronization.
    systemd[1]: Unit systemd-timesyncd.service entered failed state.
    systemd[1]: systemd-timesyncd.service failed.
    Explanation:
    systemd-journal-flush.service wants to be ordered after remote-fs.target whereas connman.service wants to be ordered before remote-fs.target. Additionally, connman.service requires basic.target. (This is implicit behavior for units which don't declare "DefaultDependencies=no".) This is why basic.target ends up getting pulled in so early in the first place.
    Furthermore, systemd-timesyncd.service relies on properly initialized runtime directories in order to work, so it wants to be ordered after systemd-tmpfiles-setup.service.
    In order to be able to start basic.target, systemd breaks the ordering cycle by taking systemd-tmpfiles-setup.service out of the transaction, thereby preventing systemd-timesyncd.service from starting up correctly.
    Last edited by csn (2014-11-01 22:18:37)

  • Several systemd services failed on fresh installation

    Hi, I installed Arch with the latest iso a few weeks ago.
    Now I saw services failing.
    I disabled everything that refers to krb (kerberos), because I don't need it yet.
    But there are 2 failed services left, I don't know how to solve them loading. Or If it is a good idea to disable them too, because I don't know what they are for:
    mdadm.service
    systemd-journal-upload.service
    Thank you for your help.
    JD

    mdadm is for RAID. And for all systemd services, you can read the relevant man page to see what it does.
    Not a Sysadmin issue, moving to NC....

  • [SOLVED] Dovecot Systemd Service Fails

    Hello all, I can't find the reason for why my dovecot fails. My journalctl doesn't provide output for the PID I give it.
    $ systemctl status dovecot.service
    * dovecot.service - Dovecot IMAP/POP3 email server
    Loaded: loaded (/usr/lib/systemd/system/dovecot.service; enabled)
    Active: failed (Result: exit-code) since Mon 2014-08-04 17:53:27 UTC; 1min 4s ago
    Process: 4580 ExecStart=/usr/bin/dovecot -F (code=exited, status=89)
    Main PID: 4580 (code=exited, status=89)
    $ journalctl -b _PID=4580
    -- Logs begin at Fri 2013-03-29 01:07:20 UTC, end at Mon 2014-08-04 02:50:51 UTC. --
    Thank you for the help.
    ========================
    EDIT:
    ran the process described above: dovecot -F which gave me the dovecot error message. I had a misconfigured file (spelling mistake).
    Thanks for the help!
    Last edited by lexan (2014-08-04 18:11:28)

    Padfoot wrote:
    Try the following:
    [Unit]
    Description=K Display Manager
    Conflicts=[email protected]
    After=systemd-user-sessions.service [email protected]
    [Service]
    ExecStart=/usr/bin/kdm -nodaemon
    Restart=always
    IgnoreSIGPIPE=no
    StandardOutput=syslog
    [Install]
    Alias=display-manager.service
    Thank you for your suggestion. Unfortunately it does not work. Out of 4 boots, 3 time I ended up with blank screen. Interestingly, in the last boot I was able to switch to tty1 just after screen went blank and managed to log in to tty. I've restarted the kdm.service then manually in hope the image will be restored, but it wasn't. The restart of kdm then made the screen totally blank and I was unable to switch to tty anymore.
    Is it possible that radeon module in kernel has some slow initialization procedure and if X requires its services before it is properly initialized it ends up with blank screen?

  • [solved] systemd services not starting at boot (or at all)

    On my router, some systemd services fail to start at boot.
    The services are :
    adsl (pppoe connetction on the wan interface)
    shorewall (funny again for a router)
    logind (brings up only tty1, and not the others with a 'timeout' error)
    adsl starts fine manually after booting up
    the others don't work, I have to launch shorewall with the old sysvinit rc script (and it works)
    I really don't know, what happened to logind...
    Last edited by scar (2012-11-30 10:20:44)

    cups: avahi client failed
    adsl: timeout (ppp0 running on eth0, the service did not found eth0)
    shorewall: did not work by the systemctl command, only with the old rc script
    I'm not sure if there was an error with logind, but I've had only tty1, not all the others (I have not touched /etc/inittab)
    since this was a very old install (but up to date), I've decided to reinstall the whole thing,
    Everything works
    (But reinstalling does not solve any problem, it erases the problems...)
    Last edited by scar (2012-11-30 10:21:20)

  • Dhcpcd-based network fails during boot

    Hi,
    My fully updated Arch_X86-64/KDE is connected to the Internet router via (on-board wired) eth1, and is configured to get an auto IP address.
    This has worked flawlessly for years till two days ago.
    Ever since,  eth1 service fails during boot, and requires several manual dhcpcd command to finally kick in. The same applies after waking from sleep mode. (see terminal output below)
    As can be seen the system is configured to load the (correct) r8169 mode.
    Please advise.
    Thanks
    Miki Badt
    ---------copy of respective commands---------------
    # journalctl -b | grep eth
    Sep 15 15:50:17 Miki_Arch systemd[1]: Expecting device sys-subsystem-net-devices-eth1.device...
    Sep 15 15:50:17 Miki_Arch systemd[1]: Expecting device sys-subsystem-net-devices-eth0.device...
    Sep 15 15:50:17 Miki_Arch kernel: r8169 0000:05:00.0 eth0: RTL8168d/8111d at 0xffffc900119d2000, 6c:f0:49:ed:b3:e9, XID 083000c0 IRQ 49
    Sep 15 15:50:17 Miki_Arch kernel: r8169 0000:05:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
    Sep 15 15:50:17 Miki_Arch kernel: r8169 0000:06:00.0 eth1: RTL8168d/8111d at 0xffffc900119e6000, 6c:f0:49:ed:b3:eb, XID 083000c0 IRQ 50
    Sep 15 15:50:17 Miki_Arch kernel: r8169 0000:06:00.0 eth1: jumbo features [frames: 9200 bytes, tx checksumming: ko]
    Sep 15 15:50:23 Miki_Arch dhcpcd[339]: eth1: waiting for carrier
    Sep 15 15:50:23 Miki_Arch dhcpcd[336]: eth0: waiting for carrier
    Sep 15 15:50:29 Miki_Arch kernel: r8169 0000:06:00.0 eth1: link down
    Sep 15 15:50:29 Miki_Arch kernel: r8169 0000:06:00.0 eth1: link down
    Sep 15 15:50:29 Miki_Arch kernel: IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
    Sep 15 15:50:29 Miki_Arch kernel: r8169 0000:05:00.0 eth0: link down
    Sep 15 15:50:29 Miki_Arch kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
    Sep 15 15:50:53 Miki_Arch systemd[1]: [email protected]: control process exited, code=exited status=1
    Sep 15 15:50:53 Miki_Arch systemd[1]: Failed to start dhcpcd on eth0.
    Sep 15 15:50:53 Miki_Arch systemd[1]: Unit [email protected] entered failed state.
    Sep 15 15:50:53 Miki_Arch systemd[1]: [email protected]: control process exited, code=exited status=1
    Sep 15 15:50:53 Miki_Arch systemd[1]: Failed to start dhcpcd on eth1.
    Sep 15 15:50:53 Miki_Arch systemd[1]: Unit [email protected] entered failed state.
    #manual commands
    [root@Miki_Arch miki]# dhcpcd eth1
    dhcpcd[1039]: version 6.0.5 starting
    dhcpcd[1039]: eth1: waiting for carrier
    dhcpcd[1039]: timed out
    dhcpcd[1039]: exited
    [root@Miki_Arch miki]# ping www.ynet.co.il
    ping: unknown host www.ynet.co.il
    [root@Miki_Arch miki]# dhcpcd eth1
    dhcpcd[1046]: version 6.0.5 starting
    dhcpcd[1046]: eth1: soliciting an IPv6 router
    dhcpcd[1046]: eth1: rebinding lease of 192.168.1.13
    dhcpcd[1046]: eth1: leased 192.168.1.13 for 3600 seconds
    dhcpcd[1046]: eth1: adding host route to 192.168.1.13 via 127.0.0.1
    dhcpcd[1046]: eth1: adding route to 192.168.1.0/24
    dhcpcd[1046]: eth1: adding default route via 192.168.1.1
    lspci -v | grep Ethernet
    05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 03)
    06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 03)
    lspci -k
    05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 03)
    Subsystem: Gigabyte Technology Co., Ltd Motherboard
    Kernel driver in use: r8169
    Kernel modules: r8169
    06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 03)
    Subsystem: Gigabyte Technology Co., Ltd Motherboard
    Kernel driver in use: r8169
    Kernel modules: r8169
    cat /etc/modules-load.d/realtek.conf
    r8169
    Last edited by mibadt (2013-09-15 13:29:25)

    Hi,
    I've some errors with the new dhcpcd, you should downgrade.
    https://wiki.archlinux.org/index.php/Do … g_Packages

  • Tip regarding the "systemd[1]: Failed to start Journal Service" error

    Just a tip regarding the well-known
    systemd[1]: Failed to start Journal Service
    error (which I ran into last weekend) to maybe save one or two among you a couple of hours of your time:
    The error is described here https://bbs.archlinux.org/viewtopic.php?id=151012 as well as in several other threads in other language boards / in other forums etc. It is usually (as in the linked thread) 'solved' by reinstalling the system - good old Windows magic, also useful when dealing with systemd.
    The Problem with this error is that you do not get into your system. Instead, systemd will print you the mentioned "Failed to start Journal Service" error message a couple of million times. There are also no logs that you could retrieve (when booting from a livesystem) and that would give you any helpful hints, since journal is systemd's logging service, old-style system logs are not kept, and the dmesg log doesn't survive the reboot with default settings.
    As pointed out in the above mentioned thread, you will see a few more instructive error messages when adding 'emergency' to the kernel line in the bootloader config.
    Now there may be plenty of reasons why the systemd journal service might not work. The most common and most annoying, however, appears to be this one:
    In this case you will see that the problem actually lies in
    systemd[1]: Cannot open /etc/machine-id: No such file or directory
    Now, 'man machine-id' reveals that "the /etc/machine-id file contains the unique machine id of the local system that is set during installation. (...) The machine ID is usually generated from a random source (...)". It is obviously perfectly justified to refuse to boot the system because an absolutely insignificant random number is missing. As far as systemd is concerned anyway.
    Usually, it seems, the /etc/machine-id is set by /usr/bin/systemd-machine-id-setup during installation or system upgrade. It is not documented anywhere that this is a rather important step and that you should better check if this was or was not actually done before rebooting. Obviously (but for no apparent reasons) systemd fails to run this (or to run this successfully) sometimes.
    Also to be recommended: Always retain (back up) your old kernel and initramfs and edit your bootloader config appropriately to be able to boot with your old kernel again ... just to have one or two options left to get back into the system in case of running into an unpleasant surprise from the side of systemd or other packages.
    The solution is, obviously, to create this file /etc/machine-id ... You probably want to do that from a livesystem (if you want to try it from the emergency shell, you would need to remount / (i.e. root) as rw and hope that systemd will not punish you for that) by just running the program that was designed for creating this file manually:  /usr/bin/systemd-machine-id-setup
    http://permalink.gmane.org/gmane.comp.s … devel/7528 states that it might also work with merely creating the file 'touch /etc/machine-id'. Though I didn't try that since I had enough fun with systemd for one week and didn't want to break my system again just to see if that works.

    Jristz wrote:
    ackalker wrote:Sorry for necrobumping this.
    Generating the machine-id in a consistent way is very important when working with KVM and containers, where the machine-id can be set for the VM or container. See `man systemd-machine-id-setup`.
    Again, _don't_ just put some random UUID in there, especially not in the systemd package install script, this makes provisioning Arch Linux containers a PITA.
    If you thing that the way that arch is handlynbg the machine-id is wrong or can be improved, then file a bug.
    He already did.
    Jristz wrote:Anyway, I thing if reinstalling systemd package or if systemd have a command to reinitialize the machine-id file.
    Like so many of your posts, I had to read this a half dozen times before it made any sense. I think you're hinting at the utility that ackalker already pointed out in the post you're replying to. And, if you read the install scriptlet, you wouldn't need to think about whether or not reinstalling would be an option. You would know that it isn't.

  • [solved] What makes systemd-logind.service fail?

    After last update made yesterday I was unable to reboot. With the help of an installation cd  and chrooting I disabled my graphical login manager lxdm which, when started, seems to do nothing and the system is stuck.
    Without lxdm service enabled, I can start xfce4 with
    startxfce4
    from commandline and everything seems to run fine. 
    But the booting process gives me several messages telling that the service systemd-logind failed. Apart from the virtual console created while booting and the one running X11 there is no other one (no login prompt when pressing strg+alt f3 e.g.)
    [root@amd64-archlinux ~]# systemctl status systemd-logind
    ● systemd-logind.service - Login Service
    Loaded: loaded (/usr/lib/systemd/system/systemd-logind.service; static)
    Active: failed (Result: start-limit) since Sun 2014-06-08 19:09:24 CEST; 5min ago
    Docs: man:systemd-logind.service(8)
    man:logind.conf(5)
    http://www.freedesktop.org/wiki/Software/systemd/logind
    http://www.freedesktop.org/wiki/Software/systemd/multiseat
    Process: 336 ExecStart=/usr/lib/systemd/systemd-logind (code=exited, status=1/FAILURE)
    Main PID: 336 (code=exited, status=1/FAILURE)
    Status: "Shutting down..."
    Jun 08 19:09:24 amd64-archlinux systemd[1]: Failed to start Login Service.
    Jun 08 19:09:24 amd64-archlinux systemd[1]: Unit systemd-logind.service entered failed state.
    Jun 08 19:09:24 amd64-archlinux systemd[1]: systemd-logind.service has no holdoff time, scheduling restart.
    Jun 08 19:09:24 amd64-archlinux systemd[1]: Stopping Login Service...
    Jun 08 19:09:24 amd64-archlinux systemd[1]: Starting Login Service...
    Jun 08 19:09:24 amd64-archlinux systemd[1]: systemd-logind.service start request repeated too quickly, refusing to start.
    Jun 08 19:09:24 amd64-archlinux systemd[1]: Failed to start Login Service.
    Jun 08 19:09:24 amd64-archlinux systemd[1]: Unit systemd-logind.service entered failed state.
    Has anyone an idea where to lead me?
    Last edited by bernd_b (2014-06-09 11:20:21)

    I don't know if I got you point - but here is a try:
    I am running X11 started manually with "startxfce4". So firing up a konsole in X11 I do and get
    root@amd64-archlinux pkg]# systemctl stop systemd-logind
    [root@amd64-archlinux pkg]# systemctl start systemd-logind
    Job for systemd-logind.service failed. See 'systemctl status systemd-logind.service' and 'journalctl -xn' for details.
    journalctl -xn:
    -- Unit systemd-logind.service has begun shutting down.
    Jun 08 21:38:18 amd64-archlinux systemd[1]: Starting Login Service...
    -- Subject: Unit systemd-logind.service has begun with start-up
    -- Defined-By: systemd
    -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
    -- Unit systemd-logind.service has begun starting up.
    Jun 08 21:38:18 amd64-archlinux systemd[1]: systemd-logind.service start request repeated too quickly, refusing to start.
    Jun 08 21:38:18 amd64-archlinux systemd[1]: Failed to start Login Service.
    -- Subject: Unit systemd-logind.service has failed
    -- Defined-By: systemd
    -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
    -- Unit systemd-logind.service has failed.
    -- The result is failed.
    I ran the service directly I get:
    [root@amd64-archlinux pkg]# /usr/lib/systemd/systemd-logind
    Failed to connect to system bus: No such file or directory
    Failed to fully start up daemon: No such file or directory
    What I figured out so far is this in addition:
    - krusader does not start- there is no response or message in the konsole when firing up this application.
    - I can only mount nfs-shares with the option "-o nolock" otherwise I get, e.g.
    mount.nfs: rpc.statd is not running but is required for remote locking.
    mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
    mount.nfs: an incorrect mount option was specified
    Last edited by bernd_b (2014-06-08 19:48:43)

  • Systemd-remount-fs.service fails [SOLVED]

    After a fresh install on a brandnew laptop, my root partition is being mounted read only, and I see that systemd-remount-fs.service fails:
    [root@anton ~]# systemctl status systemd-remount-fs.service
    systemd-remount-fs.service - Remount Root and Kernel File Systems
    Loaded: loaded (/usr/lib/systemd/system/systemd-remount-fs.service; static)
    Active: failed (Result: exit-code) since Sat, 2012-12-01 21:00:05 MST; 18min ago
    Docs: man:systemd-remount-fs.service(8)
    Process: 186 ExecStart=/usr/lib/systemd/systemd-remount-fs (code=exited, status=1/FAILURE)
    CGroup: name=systemd:/system/systemd-remount-fs.service
    Dec 01 21:00:05 anton systemd-remount-fs[186]: mount: / not mounted or bad option
    Dec 01 21:00:05 anton systemd-remount-fs[186]: In some cases useful info is found in syslog - try
    Dec 01 21:00:05 anton systemd-remount-fs[186]: dmesg | tail or so
    Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.
    I have no idea why this is happening, or what to do to try and fix it - any help/advice would be greatly appreciated.  Following is the information I think is necessary for assistance:
    Note that I have /usr on a separate partition, which I suspect is possibly involved in the issue somehow.
    Here's my fstab:
    [root@anton ~]# cat /etc/fstab
    # /dev/sda5
    #UUID=a09ff37e-ce60-4173-b95a-4b71a53c01d3 / ext4 defaults,rw,noatime,discard,data=writeback 0 1
    # /dev/sda6
    UUID=f4ab3551-c4f8-4e77-97bb-cc754c81af24 /usr ext4 defaults,noatime,discard,data=writeback 0 0
    # /dev/sda7
    UUID=c8d2776b-faaa-4a9d-ad49-4b09489faaaa /var ext4 defaults,rw,noatime,discard 0 2
    # /dev/sda8
    UUID=3dff3fa5-3291-4227-907a-258f12e1b3cf /home ext4 defaults,rw,relatime,discard 0 2
    Here's the relevant output from mount (note that my root (sda5) partition is not being mount with the options I specified in fstab):
    [root@anton ~]# mount | grep sda
    /dev/sda5 on / type ext4 (ro,relatime,data=ordered)
    /dev/sda6 on /usr type ext4 (rw,noatime,discard,data=writeback)
    /dev/sda7 on /var type ext4 (rw,noatime,discard,data=ordered)
    /dev/sda8 on /home type ext4 (rw,relatime,discard,data=ordered)
    Relavant snippet from /boot/grub/grub.cfg:
    menuentry 'Arch GNU/Linux, with Linux core repo kernel' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-core repo kernel-true-a09ff37e-ce60-4173-b95a-4b71a53c01d3' {
    load_video
    set gfxpayload=keep
    insmod gzio
    insmod part_msdos
    insmod ext2
    set root='hd0,msdos5'
    if [ x$feature_platform_search_hint = xy ]; then
    search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos5 --hint-efi=hd0,msdos5 --hint-baremetal=ahci0,msdos5 a09ff37e-ce60-4173-b95a-4b71a53c01d3
    else
    search --no-floppy --fs-uuid --set=root a09ff37e-ce60-4173-b95a-4b71a53c01d3
    fi
    echo 'Loading Linux core repo kernel ...'
    linux /boot/vmlinuz-linux root=UUID=a09ff37e-ce60-4173-b95a-4b71a53c01d3 ro init=/usr/lib/systemd/systemd
    echo 'Loading initial ramdisk ...'
    initrd /boot/initramfs-linux.img
    Finally, here's my mkinitcpio.cfg:
    [root@anton ~]# cat /etc/mkinitcpio.conf
    MODULES=""
    BINARIES=""
    FILES=""
    HOOKS="base udev autodetect sata filesystems usbinput usr fsck shutdown"
    Last edited by corey_s (2012-12-02 08:57:35)

    Thanks for the quick response, WonderWoofy ( by the way, great username! )!
    When I removed or modified the the mount options in the bootloader kernel command line, there was no change to the status of the fs after boot-up. I had changed it at one point from 'ro', to 'rw'; but doing so had no affect on the output of the mount command.
    However, I did finally identify the cause:  turns out if I specify 'data=writeback', in fstab for the root partition, then systemd-remount-fs.service fails, as per my OP - leaving me with a 'ro'-mounted root filesystem. Simply removing that, or changing it to 'data=ordered', solved the issue: when I rebooted, the root partition was mounted as per my fstab config.
    So, my fstab now looks like this:
    # /dev/sda5
    UUID=a09ff37e-ce60-4173-b95a-4b71a53c01d3 / ext4 rw,noatime,discard 0 1
    # /dev/sda6
    UUID=f4ab3551-c4f8-4e77-97bb-cc754c81af24 /usr ext4 defaults,ro,noatime,discard,data=writeback 0 0
    # /dev/sda7
    UUID=c8d2776b-faaa-4a9d-ad49-4b09489faaaa /var ext4 defaults,rw,noatime,discard 0 2
    # /dev/sda8
    UUID=3dff3fa5-3291-4227-907a-258f12e1b3cf /home ext4 defaults,rw,relatime,discard 0 2
    ... and all is now well.
    I'll mark this as solved, but I'll also ask:  why does specifying 'data=writeback' on my root partition cause the systemd-remount-fs.service to fail? Any experts out there know?
    Last edited by corey_s (2012-12-02 06:46:32)

  • [SOLVED]systemd-tmpfiles-setup.service fails

    Hi,
    I have installed arch on an old laptop (dell inspiron 6000). I haven't used arch linux for last 2 years. It seems system management style has changed drastically.
    Anyways, systemctl status systemd-tmpfiles-setup.service returns this;
    ● systemd-tmpfiles-setup.service - Create Volatile Files and Directories
    Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-setup.service; static; vendor preset: disabled)
    Active: failed (Result: exit-code) since Sal 2015-06-09 11:00:18 EEST; 38min ago
    Docs: man:tmpfiles.d(5)
    man:systemd-tmpfiles(8)
    Process: 228 ExecStart=/usr/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev (code=exited, status=1/FAILURE)
    Main PID: 228 (code=exited, status=1/FAILURE)
    Haz 09 11:00:18 yasar-laptop systemd[1]: Starting Create Volatile Files and Directories...
    Haz 09 11:00:18 yasar-laptop systemd[1]: systemd-tmpfiles-setup.service: main process exited, code=exited, status=1/FAILURE
    Haz 09 11:00:18 yasar-laptop systemd[1]: Failed to start Create Volatile Files and Directories.
    Haz 09 11:00:18 yasar-laptop systemd[1]: Unit systemd-tmpfiles-setup.service entered failed state.
    Haz 09 11:00:18 yasar-laptop systemd[1]: systemd-tmpfiles-setup.service failed.
    Is this something that I should be concerned? I don't really know what this service supposed to do?
    If I should be concerned, how to troubleshoot it? Keep in mind that this is a fresh arch install.
    Last edited by yasar11732 (2015-06-09 16:31:04)

    Thanks,
    I have add acl option to fstab file, it works now. If anyone else has this problem, here is how my fstab file looks now;
    # /etc/fstab: static file system information
    # <file system> <dir> <type> <options> <dump> <pass>
    UUID=936297ec-2bc3-45ef-bdb0-0a4ce7239204 / ext4 rw,relatime,data=ordered 0 1
    UUID=d1fd9d31-99b5-45ba-97f4-a4c20b96e48b /var reiserfs rw,relatime,acl 0 2
    UUID=6a9b3e39-8ea2-446f-9a71-79faab7cdafe /home xfs rw,relatime,attr2,inode64,noquota 0 2
    # UUID=eb0b40d3-43ac-4f1f-8b29-97cd16a534d4
    UUID=eb0b40d3-43ac-4f1f-8b29-97cd16a534d4 none swap defaults 0 0

  • Systemd-hostnamed.service fails to start

    I'm finding the systemd-hostnamed.service isnt working
    $ sudo systemctl --state=failed
    [sudo] password for kevdog:
    UNIT LOAD ACTIVE SUB DESCRIPTION
    ● systemd-hostnamed.service loaded failed failed Hostname Service
    LOAD = Reflects whether the unit definition was properly loaded.
    ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
    SUB = The low-level unit activation state, values depend on unit type.
    1 loaded units listed. Pass --all to see loaded but inactive units, too.
    To show all installed unit files use 'systemctl list-unit-files'.
    $ sudo systemctl status systemd-hostnamed.service
    ● systemd-hostnamed.service - Hostname Service
    Loaded: loaded (/usr/lib/systemd/system/systemd-hostnamed.service; static)
    Active: failed (Result: timeout) since Tue 2014-12-16 23:11:36 CST; 10min ago
    Docs: man:systemd-hostnamed.service(8)
    man:hostname(5)
    man:machine-info(5)
    http://www.freedesktop.org/wiki/Software/systemd/hostnamed
    Main PID: 4584
    Dec 16 23:08:35 orphan systemd[1]: systemd-hostnamed.service start operation timed out. Terminating.
    Dec 16 23:10:06 orphan systemd[1]: systemd-hostnamed.service stop-final-sigterm timed out. Killing.
    Dec 16 23:11:36 orphan systemd[1]: systemd-hostnamed.service still around after final SIGKILL. Entering failed mode.
    Dec 16 23:11:36 orphan systemd[1]: Failed to start Hostname Service.
    Dec 16 23:11:36 orphan systemd[1]: Unit systemd-hostnamed.service entered failed state.
    Dec 16 23:11:36 orphan systemd[1]: systemd-hostnamed.service failed.
    I found this addressed in this topic:
    https://github.com/ev3dev/ev3dev/issues/189
    Within this page they state:
    Confirmed that removing PrivateNetwork=yes from the service file works as a workaround. Maybe need to enable CONFIG_NAMESPACES=y and CONFIG_NET_NS=y kernel modules
    I removed the PrivateNetwork=yes from the service file, however this didn't seem to work.  I did not enable the kernel modules.  I am currently running the following kernel: 3.17.6-1-ARCH
    Thanks

    I'm finding the systemd-hostnamed.service isnt working
    $ sudo systemctl --state=failed
    [sudo] password for kevdog:
    UNIT LOAD ACTIVE SUB DESCRIPTION
    ● systemd-hostnamed.service loaded failed failed Hostname Service
    LOAD = Reflects whether the unit definition was properly loaded.
    ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
    SUB = The low-level unit activation state, values depend on unit type.
    1 loaded units listed. Pass --all to see loaded but inactive units, too.
    To show all installed unit files use 'systemctl list-unit-files'.
    $ sudo systemctl status systemd-hostnamed.service
    ● systemd-hostnamed.service - Hostname Service
    Loaded: loaded (/usr/lib/systemd/system/systemd-hostnamed.service; static)
    Active: failed (Result: timeout) since Tue 2014-12-16 23:11:36 CST; 10min ago
    Docs: man:systemd-hostnamed.service(8)
    man:hostname(5)
    man:machine-info(5)
    http://www.freedesktop.org/wiki/Software/systemd/hostnamed
    Main PID: 4584
    Dec 16 23:08:35 orphan systemd[1]: systemd-hostnamed.service start operation timed out. Terminating.
    Dec 16 23:10:06 orphan systemd[1]: systemd-hostnamed.service stop-final-sigterm timed out. Killing.
    Dec 16 23:11:36 orphan systemd[1]: systemd-hostnamed.service still around after final SIGKILL. Entering failed mode.
    Dec 16 23:11:36 orphan systemd[1]: Failed to start Hostname Service.
    Dec 16 23:11:36 orphan systemd[1]: Unit systemd-hostnamed.service entered failed state.
    Dec 16 23:11:36 orphan systemd[1]: systemd-hostnamed.service failed.
    I found this addressed in this topic:
    https://github.com/ev3dev/ev3dev/issues/189
    Within this page they state:
    Confirmed that removing PrivateNetwork=yes from the service file works as a workaround. Maybe need to enable CONFIG_NAMESPACES=y and CONFIG_NET_NS=y kernel modules
    I removed the PrivateNetwork=yes from the service file, however this didn't seem to work.  I did not enable the kernel modules.  I am currently running the following kernel: 3.17.6-1-ARCH
    Thanks

  • Systemd fails on boot

    After running systemd with absolutely no issues for a good month or two, my arch setup fails to boot with a cascade of errors, the first of which is
    [Failed] Failed to start Setup Virtual Console
    Consequently, I can't even get a terminal to attempt diagnostics. Using a live CD to create /var/log/journal/ for persistent logs (as instructed by the wiki) seems useless as nothing is saved to that directory.
    Are there any diagnostic or repair steps I can take, or is my best bet to back up my files off of that partition and reinstall Arch?
    Last edited by slavik262 (2012-09-26 23:38:03)

    slavik262 wrote:
    archie0 wrote:I'm not sure this helps, but did you configure your /etc/vconsole.conf?
    https://wiki.archlinux.org/index.php/Sy … and_keymap
    I don't believe I have one set up, but the defaults should be just fine. My other arch setup on my laptop doesn't have vconsole.conf and I'm having no issues.
    By default, the file should be empty. Are you using SystemD on your laptop as well?

Maybe you are looking for

  • Does a ibook G4 have a clock battery?

    I am using the 1.2ghz ibook G4 I bought last May. Does it have a clock battery? Last night I accidently left my ibook's battery out of the unit. Then I came to it today, only to find the date and time reset. Ths has led me to believe that the ibook l

  • Command-C doesn't work

    Hello everybody, your help would be greatly appreciated. All of a sudden, my CMND-C stopped working. Every other shortcut works fine and I can still copy text or files with through the menu. Just the keyboard shortcut in itself seems not to work anym

  • When I click on my Imac to sleep, it shuts down instead

    When I click on my Imac to sleep, it shuts down instead

  • Where is Login information stored for Blackberry Browser?

    I have accessed several sites on my Passport that require usernames/passwords.  Upon entry the Browser pops up a window and asks if I want to save the login information. 1. Where is that information stored? 2. Can that information be purged/wiped? 3.

  • Dual i7 (8-core) RT system motherboard suggestions?

    Greetings LV Community, I need to duplicate a Dual Xeon (8 core) RT-PC system that we built a few years back. The motherboard we used has become obsolete, so I'm looking for a replacement motherboard that can handle two i7 quad-core processors. I'm a