You are not logged in.

#851 2011-07-18 23:10:01

tomegun
Developer
From: France
Registered: 2010-05-28
Posts: 661

Re: systemd: Yet Another Init Replacement

@Viper_Scull: no need for that. All you have to do is to disable syslog-ng.service (or rsyslog.service if that's what you use).

On next reboot all your syslog messages can be seen by using "dmesg". Nothing get's written to /var/log (except for stuff that circumvents syslog of course).

Offline

#852 2011-07-19 16:17:11

ron9
Member
From: Norway
Registered: 2011-02-02
Posts: 116

Re: systemd: Yet Another Init Replacement

tomegun wrote:

@Viper_Scull: no need for that. All you have to do is to disable syslog-ng.service (or rsyslog.service if that's what you use).

What about syslog.socket? It still loaded after disabling syslog-ng.service. Is it needed for something else?


lenovo w500 - huawei matebook 14 | archlinux | swaywm | alacritty | falkon

Offline

#853 2011-07-19 16:35:56

tomegun
Developer
From: France
Registered: 2010-05-28
Posts: 661

Re: systemd: Yet Another Init Replacement

ron9 wrote:

What about syslog.socket? It still loaded after disabling syslog-ng.service. Is it needed for something else?

syslog.socket creates /dev/log and starts systemd-kmsg-syslogd.service on demand. This is a minimal syslog implementation which just forwards all messages from /dev/log to kmesg. This is what allows you to see all your syslog messages using dmesg.

Under normal circumstances (when syslog-ng/rsyslog are enabled) the role of systemd-kmsg-syslogd.service is to catch the messages that arrive before the real syslog daemon is available.

Offline

#854 2011-07-19 17:37:24

ron9
Member
From: Norway
Registered: 2011-02-02
Posts: 116

Re: systemd: Yet Another Init Replacement

[ronny@olebrumm ~]$ systemd-analyze blame
  2813ms udev-trigger.service
  2510ms var-lock.mount
  2487ms media.mount
  2463ms var-run.mount
  1509ms systemd-vconsole-setup.service
   429ms home-ronny-mydata.mount
   399ms wireless.service
   399ms systemd-sysctl.service
   364ms systemd-readahead-collect.service
   340ms systemd-readahead-replay.service
   333ms wpa_supplicant.service
   320ms udev.service
   239ms systemd-tmpfiles-setup.service
   213ms systemd-logind.service
   176ms dbus.service
   166ms systemd-remount-api-vfs.service
   147ms home-ronny-homeserver.mount
   103ms dcron.service
    69ms systemd-user-sessions.service
    23ms remount-rootfs.service
    13ms boot.mount

Startup finished in 3458ms (kernel) + 6175ms (userspace) = 9633ms

After some testing, the result is that there is very little or no time to spare to disable syslog-ng on my system. With readahead enabled time is changing a little bit up and down for every reboot. The fastest start I've read has been just under six seconds plus kernel......
But anyway thanks for the explanation about syslog.socket and for suggestions to speedup boottime. smile


lenovo w500 - huawei matebook 14 | archlinux | swaywm | alacritty | falkon

Offline

#855 2011-07-19 17:54:46

litemotiv
Forum Fellow
Registered: 2008-08-01
Posts: 5,026

Re: systemd: Yet Another Init Replacement

ron9, your udev-trigger.service call seems quite slow, i wonder why that is.


ᶘ ᵒᴥᵒᶅ

Offline

#856 2011-07-19 20:36:09

tomegun
Developer
From: France
Registered: 2010-05-28
Posts: 661

Re: systemd: Yet Another Init Replacement

litemotiv wrote:

ron9, your udev-trigger.service call seems quite slow, i wonder why that is.

The call to trigger should be instantaneous, so (unless there is a bug in udev), this is just a side-effect of having a slow HDD.

Offline

#857 2011-07-19 22:31:46

ron9
Member
From: Norway
Registered: 2011-02-02
Posts: 116

Re: systemd: Yet Another Init Replacement

litemotiv wrote:

ron9, your udev-trigger.service call seems quite slow, i wonder why that is.

Udev-trigger.service uses between 2.5-3.5sec with readahead enabled. Mutch faster without readahead.

[ronny@olebrumm ~]$ systemd-analyze blame
  2776ms systemd-vconsole-setup.service
   959ms wireless.service
   887ms wpa_supplicant.service
   729ms systemd-remount-api-vfs.service
   678ms var-lock.mount
   663ms media.mount
   656ms systemd-logind.service
   643ms var-run.mount
   438ms home-ronny-mydata.mount
   386ms dbus.service
   386ms udev-trigger.service
   340ms udev.service
   303ms systemd-tmpfiles-setup.service
   296ms systemd-sysctl.service
   172ms systemd-user-sessions.service
   169ms home-ronny-homeserver.mount
   130ms dcron.service
    31ms boot.mount
    19ms remount-rootfs.service
     1ms dev-mqueue.mount

Startup time is almoust same with and without readahead, but as you see some services are slower with and faster without... ?

tomegun wrote:

The call to trigger should be instantaneous, so (unless there is a bug in udev), this is just a side-effect of having a slow HDD.

My HDD is a Seagate Momentus 7200rpm, sata 3Gb/s, 8mb cache. Not so slow, but in comparison with SSD....(on my wish list)  smile
But maybe slow enough to make udev.trigger.service so slow.

.


lenovo w500 - huawei matebook 14 | archlinux | swaywm | alacritty | falkon

Offline

#858 2011-07-19 22:46:45

tomegun
Developer
From: France
Registered: 2010-05-28
Posts: 661

Re: systemd: Yet Another Init Replacement

ron9 wrote:

My HDD is a Seagate Momentus 7200rpm, sata 3Gb/s, 8mb cache. Not so slow, but in comparison with SSD....(on my wish list)  smile
But maybe slow enough to make udev.trigger.service so slow.
.

Yeah, in my simplistic world view "slow==HDD", "fast==SSD" smile

To compound the issue, I believe readahead is run with real-time priority if you are on a HDD, which means that start-up of some other services will be starved and appear to take a very long time. The total time should of course (in theory) be shorter with readehead, but YMMV. There is probably a lot of low hanging fruit if you want to have a look at optimizing readahead for HDD as I believe all he main devs use SSD.

Essentially, I think "systemd-analyze blame" should be taken with a shovel of salt when using HDD.

Offline

#859 2011-07-22 04:51:29

Stebalien
Member
Registered: 2010-04-27
Posts: 1,237
Website

Re: systemd: Yet Another Init Replacement

For some reason, running net-auto-wireless (netcfg) from systemd/systemctl fails with the following error:

iwl3945 0000:0c:00.0: Error: Response NULL in 'REPLY_ADD_STA'
iwl3945 0000:0c:00.0: Adding station ff:ff:ff:ff:ff:ff failed.

.service file:

[Unit]
Description=Automatically connect to a wireless network.
Before=network.target
After=ufw.service
Wants=network.target

[Service]
Type=forking
ExecStart=/etc/rc.d/net-auto-wireless start
ExecStop=/etc/rc.d/net-auto-wireless stop

[Install]
WantedBy=default.target

Starting it manually and from the default arch initscripts works fine.

Any ideas?


Steven [ web : git ]
GPG:  327B 20CE 21EA 68CF A7748675 7C92 3221 5899 410C
Do not email: honeypot@stebalien.com

Offline

#860 2011-07-22 07:37:42

litemotiv
Forum Fellow
Registered: 2008-08-01
Posts: 5,026

Re: systemd: Yet Another Init Replacement

Stebalien wrote:

For some reason, running net-auto-wireless (netcfg) from systemd/systemctl fails with the following error:

iwl3945 0000:0c:00.0: Error: Response NULL in 'REPLY_ADD_STA'
iwl3945 0000:0c:00.0: Adding station ff:ff:ff:ff:ff:ff failed.

Try this one:

[Unit]
Description=Automatically connect to wireless network
Requires=wireless-regdom.service
After=wireless-regdom.service

[Service]
Type=forking
ExecStart=/usr/bin/netcfg-wpa_actiond wlan0 
ExecStop=/usr/bin/netcfg-wpa_actiond stop wlan0 
StandardOutput=syslog

[Install]
WantedBy=multi-user.target

ᶘ ᵒᴥᵒᶅ

Offline

#861 2011-07-22 16:42:27

Stebalien
Member
Registered: 2010-04-27
Posts: 1,237
Website

Re: systemd: Yet Another Init Replacement

I don't have wireless-regdom.service so I used sys-subsystem-devices-net-wlan0.device instead. Thanks.

[Unit]
Description=Automatically connect to a wireless network.
After=ufw.service sys-subsystem-devices-net-wlan0.device

[Service]
Type=forking
EnvironmentFile=/etc/rc.conf
ExecStart=/usr/bin/netcfg-wpa_actiond ${WIRELESS_INTERFACE}
ExecStop=/usr/bin/netcfg-wpa_actiond stop ${WIRELESS_INTERFACE}
StandardOutput=syslog

[Install]
WantedBy=multi-user.target

Last edited by Stebalien (2011-07-22 16:42:50)


Steven [ web : git ]
GPG:  327B 20CE 21EA 68CF A7748675 7C92 3221 5899 410C
Do not email: honeypot@stebalien.com

Offline

#862 2011-07-24 09:42:38

ato10
Member
Registered: 2010-03-07
Posts: 12

Re: systemd: Yet Another Init Replacement

Have someone problem with the last kernel in testing?
It doesn't work for me.

Offline

#863 2011-07-24 11:34:39

tomegun
Developer
From: France
Registered: 2010-05-28
Posts: 661

Re: systemd: Yet Another Init Replacement

ato10 wrote:

Have someone problem with the last kernel in testing?
It doesn't work for me.

I think you'd have to provide a bit more details. Is it strictly systemd related? It is probably worth filing a bug report.

Offline

#864 2011-07-24 12:25:09

ato10
Member
Registered: 2010-03-07
Posts: 12

Re: systemd: Yet Another Init Replacement

You right wink
I'd like to know is if there is any known problem, otherwise I will try to fend

Offline

#865 2011-07-24 12:37:01

eworm
Trusted User (TU)
From: Oberhausen, Germany
Registered: 2010-01-30
Posts: 104
Website

Re: systemd: Yet Another Init Replacement

Works fine here... Without any problems so far.

14:35:48 root@leda:~# uname -a
Linux leda 3.0.0-ARCH #1 SMP PREEMPT Sat Jul 23 23:17:54 CEST 2011 x86_64 Intel(R) Atom(TM) CPU N550 @ 1.50GHz GenuineIntel GNU/Linux
14:35:52 root@leda:~# ps 1
  PID TTY      STAT   TIME COMMAND
    1 ?        Ss     0:02 /bin/systemd

ArchLinux - make it simple & lightweight

Offline

#866 2011-07-24 13:58:33

ato10
Member
Registered: 2010-03-07
Posts: 12

Re: systemd: Yet Another Init Replacement

eworm wrote:

Works fine here... Without any problems so far.

thanks for reply.
it was my mistake with syslog-ng which has clogged the log and I forgot to recompile the nvidia-beta. everything works now

Offline

#867 2011-07-27 18:44:55

framas
Member
Registered: 2009-07-24
Posts: 50

Re: systemd: Yet Another Init Replacement

This days I experimented a little bittle to get the automount feature work with truecrypt.
On the gentoo wiki I found a little mount script to enable truecrypt in fstab which I extend a little by myself.

cat /sbin/mount.truecrypt

#!/usr/bin/env sh
function log(){
logger -t "mount.truecrypt" " ${1}"
}

if [ -z ${USER} ]
then
        _user=frank
else
        _user=${USER}
fi

export DISPLAY=:0
DEV="$1"
MNTPT="$2"
OPTIONS=""
TCOPTIONS=""
export XAUTHORITY=/home/${_user}/.Xauthority
shift 3
IFS=','
for arg in $*; do
    if [ "${arg}" == "system" ]; then
        TCOPTIONS="${TCOPTIONS}-m=system "                                                                                                                                       
    elif [[ "${arg}" == fs=* ]]; then                                                                                                                                            
        FS=${arg#*=}                                                                                                                                                             
        TCOPTIONS="${TCOPTIONS}--filesystem=${FS} "                                                                                                                              
    else                                                                                                                                                                         
        OPTIONS="${OPTIONS}${arg},"                                                                                                                                              
    fi                                                                                                                                                                           
done                                                                                                                                                                             
if [ -z "$(mount | grep ${MNTPT})" ]                                                                                                                                             
then                                                                                                                                                                             
        command="/usr/bin/sudo /usr/bin/truecrypt ${DEV} ${MNTPT} ${TCOPTIONS% *} --fs-options=\"${OPTIONS%,*}\""                                                                
        log "Running ${command} as user ${_user}"                                                                                                                                
        eval "${command}"                                                                                                                                                        
        if [ $? -eq 0 ]                                                                                                                                                          
        then                                                                                                                                                                     
                log "${MNTPT} successfully mounted"                                                                                                                              
        else                                                                                                                                                                     
                log "truecrypt returned $?"                                                                                                                                      
                exit $?                                                                                                                                                          
        fi                                                                                                                                                                       
else
        log "${MNTPT} is already mounted"
fi

In the next step I put a entry to fstab

/dev/sdb9 /media/private truecrypt       fs=ext4,noauto,defaults,user  0 0

The script works as expected when I call mount /media/privat.
As the next step my idea was to put this in an automount unit.

comment=systemd.automount

in the fstab does not work so I wrote my own units.
The mount unit:

[Unit]
Description=Mount private directory via truecrypt
After=kdm.service

[Mount]
What=/dev/sdb9
Where=/media/private
Type=truecrypt                                                                                                                                                                   
StandardOutput=syslog                                                                                                                                                            
StandardError=syslog                                                                                                                                                             
Options=fs=ext4                                                                                                                                                                  
DirectoryMode=750     

The automount unit:

[Unit]                                                                                                                                                                           
Description=Mount private directory via truecrypt                                                                                                                                
After=kdm.service

[Automount]
Where=/media/private

[Install]
WantedBy=graphical.target

The problem now is that I cannot get the unit to start automatically during system startup / xsession startup or whatever I had to put this...
When I put this units after media.mount instead of kdm.service systemd hangs during startup because it wants to launch truecrypt.
Whith After=kdm.service kde is started normally but the unit is marked as death.
When I enable and start the service manually in X it works as expected when I try to access /media/private.
So I think I had to find the right start point for this unit and that's the point I want ask for help from you.

PS: I run kdm with autologon.

Offline

#868 2011-07-27 19:33:32

Wey
Member
Registered: 2011-04-22
Posts: 217

Re: systemd: Yet Another Init Replacement

I noticed these lines in my dmesg:

[    8.637761] systemd-tmpfiles[322]: Two or more conflicting lines for /tmp configured, ignoring.
[    8.638000] systemd-tmpfiles[322]: Two or more conflicting lines for /tmp/.X11-unix configured, ignoring.
[    8.638009] systemd-tmpfiles[322]: Two or more conflicting lines for /tmp/.ICE-unix configured, ignoring.
[    8.638017] systemd-tmpfiles[322]: Two or more conflicting lines for /tmp/.XIM-unix configured, ignoring.
[    8.638037] systemd-tmpfiles[322]: Two or more conflicting lines for /tmp/.font-unix configured, ignoring.
[    8.638044] systemd-tmpfiles[322]: Two or more conflicting lines for /tmp/.Test-unix configured, ignoring.

I searched for the corresponding configuration files:

$ grep -rIE '(X11|ICE|XIM|font|Test)-unix' /usr
...
/usr/lib/tmpfiles.d/arch.conf:d /tmp/.X11-unix    1777 root root
/usr/lib/tmpfiles.d/arch.conf:d /tmp/.ICE-unix    1777 root root
/usr/lib/tmpfiles.d/arch.conf:d /tmp/.XIM-unix    1777 root root
/usr/lib/tmpfiles.d/arch.conf:d /tmp/.font-unix   1777 root root
/usr/lib/tmpfiles.d/arch.conf:d /tmp/.Test-unix   1777 root root
/usr/lib/tmpfiles.d/x11.conf:d /tmp/.X11-unix 1777 root root 10d
/usr/lib/tmpfiles.d/x11.conf:d /tmp/.ICE-unix 1777 root root 10d
/usr/lib/tmpfiles.d/x11.conf:d /tmp/.XIM-unix 1777 root root 10d
/usr/lib/tmpfiles.d/x11.conf:d /tmp/.font-unix 1777 root root 10d
/usr/lib/tmpfiles.d/x11.conf:d /tmp/.Test-unix 1777 root root 10d
...
$ LANG="" pacman -Qo /usr/lib/tmpfiles.d/x11.conf /usr/lib/tmpfiles.d/arch.conf 
/usr/lib/tmpfiles.d/arch.conf is owned by initscripts 2011.07.2-1
/usr/lib/tmpfiles.d/x11.conf is owned by systemd 30-1

Can i just ignore it?

Offline

#869 2011-07-27 19:41:47

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: systemd: Yet Another Init Replacement

Sure. You can uninstall initscripts, too.

Offline

#870 2011-07-27 20:09:43

Wey
Member
Registered: 2011-04-22
Posts: 217

Re: systemd: Yet Another Init Replacement

Thanks for your feedback. A native systemd setup was on my todo list for quite some time now, but i kept setting it aside.

Offline

#871 2011-07-27 23:46:34

Wey
Member
Registered: 2011-04-22
Posts: 217

Re: systemd: Yet Another Init Replacement

I guess I'm mostly done. The only issue i encountered was with the consolefont hook in mkinitcpio:

  -> Parsing hook: [consolefont]
grep: /etc/rc.conf: No such file or directory

So in /lib/initcpio/install/consolefont i replaced

eval "$(grep -e "^CONSOLEFONT=" /etc/rc.conf)"

with

eval "$(grep -e "^FONT=" /etc/vconsole.conf)"

Offline

#872 2011-07-28 13:07:06

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: systemd: Yet Another Init Replacement

Important!

If you are upgrading to v31 either by the soon to be hitting [community-testing] package or via systemd-git, please make sure you restart systemd-logind.service (via systemctl). If you do not do this, you will be locked out of SSH (and possibly more) if you are using systemd-pam (which damnit, you should be).

Update: v31 will not make to community-testing due to some blockers. I'm still undecided as to whether or not I'll add a try-restart to the install scriptlet for v32.

Last edited by falconindy (2011-07-28 14:15:50)

Offline

#873 2011-07-29 21:33:27

bart_vv
Member
From: Poland
Registered: 2011-04-12
Posts: 51

Re: systemd: Yet Another Init Replacement

I seem to have a problem with systemd + rc.local. With sysVinit I used rc.local for my laptop graphics switching (I want my discrete graphics card powered off all the time) - there were few tweaks like sleep 5 between "modprobe radeon" and "echo OFF > /sys/kernel/debug/vgaswitcheroo/switch" - otherwise it won't work(and I cannot load radeon module normally - see https://wiki.archlinux.org/index.php/Acer_TimelineX ).  "sleep x" command seems to malfunction with systemd. Can anyone confirm this? Any suggestions for workaround?

Offline

#874 2011-07-29 21:39:49

tomegun
Developer
From: France
Registered: 2010-05-28
Posts: 661

Re: systemd: Yet Another Init Replacement

bart_vv wrote:

I seem to have a problem with systemd + rc.local. With sysVinit I used rc.local for my laptop graphics switching (I want my discrete graphics card powered off all the time) - there were few tweaks like sleep 5 between "modprobe radeon" and "echo OFF > /sys/kernel/debug/vgaswitcheroo/switch" - otherwise it won't work(and I cannot load radeon module normally - see https://wiki.archlinux.org/index.php/Acer_TimelineX ).  "sleep x" command seems to malfunction with systemd. Can anyone confirm this? Any suggestions for workaround?

Could you post exactly your contents of rc.local, as well as the output of "systemctl status rc-local.service"

Offline

#875 2011-07-30 00:00:59

bart_vv
Member
From: Poland
Registered: 2011-04-12
Posts: 51

Re: systemd: Yet Another Init Replacement

It's modprobe radeon, sleep and echo OFF > /sys/kernel/debug/vgaswitcheroo/switch just as I said, nothing more:

#!/bin/bash
#
# /etc/rc.local: Local multi-user startup script.
#

modprobe radeon
sleep 5 ; echo OFF > /sys/kernel/debug/vgaswitcheroo/switch

rc-local service is enabled, it loads radeon module. It works when I run it manually, it worked with sysVinit. I know that rc.local is a bad way usually, but I think that such a simple thing should work.

rc-local.service - /etc/rc.local Compatibility
      Loaded: loaded (/lib/systemd/system/rc-local.service)
      Active: active (exited) since Sat, 30 Jul 2011 01:28:31 +0200; 3min 39s ago
     Process: 557 ExecStart=/etc/rc.local (code=killed, signal=HUP)
      CGroup: name=systemd:/system/rc-local.service

Offline

Board footer

Powered by FluxBB