You are not logged in.

#801 2011-06-26 18:20:25

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

Re: systemd: Yet Another Init Replacement

This sounds like something different. I can't reproduce on any of my VMs. If you google around, you'll find a way to bind systemctl invocation to kbrequest (ctrl-alt-up). You'll be able to see exactly what jobs are active and what's in queue. Certainly it'd be easy to rule out syslog-ng if its stopped (manually) before you shutdown.

Last edited by falconindy (2011-06-26 18:21:09)

Offline

#802 2011-06-26 19:18:48

WorMzy
Forum Moderator
From: Scotland
Registered: 2010-06-16
Posts: 11,787
Website

Re: systemd: Yet Another Init Replacement

Alright, I've got that set up. The next time I get a hang I'll see what it has to say.

Also, I'm going to have a lot of fun with custom key mappings on my VT-only install now.


Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD

Making lemonade from lemons since 2015.

Offline

#803 2011-06-27 06:13:04

sidneyk
Member
From: Bonner Springs, KS. USA
Registered: 2011-04-22
Posts: 129

Re: systemd: Yet Another Init Replacement

falconindy wrote:

I've put syslog-ng-systemd back in the AUR.

I just switched back to syslog-ng-systemd on both my laptop and desktop and all is working fine.

Offline

#804 2011-06-27 20:12:12

Viper_Scull
Member
From: London, UK
Registered: 2011-01-15
Posts: 153

Re: systemd: Yet Another Init Replacement

So far so good with syslog-ng-systemd


Athlon II X4 620 + Gigabyte 785GPM-UD2H + 4GB DDR3 + SSD OCZ Vertex2 60GB

Archlinux x86_64 + Openbox

Offline

#805 2011-06-28 12:50:38

WorMzy
Forum Moderator
From: Scotland
Registered: 2010-06-16
Posts: 11,787
Website

Re: systemd: Yet Another Init Replacement

I haven't experienced any more hangups, and since nobody else seems to have got any, I'm going to have to assume it was some kind of hardware hiccup which just coincidentally happened after I switched log apps.


Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD

Making lemonade from lemons since 2015.

Offline

#806 2011-06-28 15:02:26

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

Re: systemd: Yet Another Init Replacement

syslog-ng 3.2.4-2 is in [testing] with proper systemd support.

Offline

#807 2011-06-28 17:42:51

sidneyk
Member
From: Bonner Springs, KS. USA
Registered: 2011-04-22
Posts: 129

Re: systemd: Yet Another Init Replacement

I'm posting this here just in case anyone using systemd along with plymouth and Gnome and nVidia drivers. I don't really know why I didn't try this before, but I finally got rid of the little black squares with nVidia driver issue. I am using systemd for my init system now and plymouth only shows a splash screen during bootup now and not on shutdown like before (shutdown happens really quick anyway). I put this line "/bin/plymouth quit" in my /etc/rc.local file and have enabled the rc-local.service. Black squares gone. When I tried to use "/bin/plymouth quit --retain splash", it caused my system to hang and not go on to start gdm. The 'workaround' in the plymouth wiki never worked for me. There may well be other, better ways to accomplish this, but this way works without being too clunky.

[EDIT] Nevermind, mkinitcpio-0.7-1 update today broke plymouth for the time being.
[EDIT] The work around for the above problem was to change 'install' to 'build' and just remove the 'add_device' line. Plymouth now builds properly with mkinitcpio and works fine.

Last edited by sidneyk (2011-07-06 05:45:14)

Offline

#808 2011-06-29 20:00:12

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

Re: systemd: Yet Another Init Replacement

falconindy wrote:

A page or two ago in this thread I pointed out that /media gets mounted with a tmpfs over it. If you want your directories to stop "disappearing", mask the /lib/systemd/systemd/media.mount unit.

I tried this like you described on https://bbs.archlinux.org/viewtopic.php … 56#p948656

# systemctl stop media.mount
# ln -s /dev/null /etc/systemd/system/local-fs.target.wants/media.mount
# kill -1 1

After reboot the overlay was still created again.

So I also masked media.mount in /lib/. media.mount looks now like:

 ls -l  /{lib,etc}/systemd/system/local-fs.target.wants/media.mount                                                                                   
lrwxrwxrwx 1 root root 9 29. Jun 19:24 /etc/systemd/system/local-fs.target.wants/media.mount -> /dev/null                                                                        
lrwxrwxrwx 1 root root 9 29. Jun 20:51 /lib/systemd/system/local-fs.target.wants/media.mount -> /dev/null 

So everything seems to be ok at this side. The overlay ist still created each time I boot.
When i do a systemctl dump  and look for the media.mount unit I still seem to point to the correct file

-> Unit media.mount:
    Description: Media Directory
    Instance: n/a
    Unit Load State: loaded
    Unit Active State: active
    Inactive Exit Timestamp: Wed, 29 Jun 2011 21:09:57 +0200
    Active Enter Timestamp: Wed, 29 Jun 2011 21:09:57 +0200
    Active Exit Timestamp: n/a
    Inactive Enter Timestamp: n/a
    GC Check Good: yes
    Need Daemon Reload: no
    Name: media.mount
    Fragment Path: /lib/systemd/system/media.mount
    Condition Timestamp: Wed, 29 Jun 2011 21:09:57 +0200
    Condition Result: yes
    Requires: systemd-logger.socket
    Requires: -.mount
    RequiredBy: media-data.mount
    WantedBy: local-fs.target
    Conflicts: umount.target
    Before: local-fs.target
    Before: media-data.mount
    Before: umount.target
    After: systemd-logger.socket
    After: -.mount
    References: local-fs.target
    References: systemd-logger.socket
    References: umount.target
    References: -.mount
    ReferencedBy: local-fs.target
    ReferencedBy: media-data.mount
    StopWhenUnneeded: no
    RefuseManualStart: no
    RefuseManualStop: no
    DefaultDependencies: yes
    OnFailureIsolate: no
    IgnoreOnIsolate: yes
    IgnoreOnSnapshot: no
    ControlGroup: cpu:/system/media.mount
    ControlGroup: name=systemd:/system/media.mount
    Mount State: mounted
    Where: /media
    What: tmpfs
    File System Type: tmpfs
    Options: rw,nosuid,nodev,noexec,relatime,rw,mode=755
    From /etc/fstab: no
    From /proc/self/mountinfo: yes
    From fragment: yes
    DirectoryMode: 0755
    UMask: 0002
    WorkingDirectory: /
    RootDirectory: /
    NonBlocking: no
    PrivateTmp: no
    StandardInput: null
    StandardOutput: kmsg
    StandardError: inherit
    SyslogFacility: daemon
    SyslogLevel: info
    KillMode: control-group
    KillSignal: SIGTERM
    SendSIGKILL: yes

So don't know why this is not working here.  I will try the tmpfs method next.

Offline

#809 2011-06-29 20:13:43

Zom
Member
From: Sweden
Registered: 2007-10-27
Posts: 430

Re: systemd: Yet Another Init Replacement

Just a heads up from the mailing list, but seems like newer versions of systemd won't actually start a getty until you switch to it.

Personally, I think this sounds cool, but someone might be confused when the change comes. smile

Offline

#810 2011-06-29 20:19:28

henny
Member
Registered: 2011-06-15
Posts: 10

Re: systemd: Yet Another Init Replacement

framas wrote:
falconindy wrote:

A page or two ago in this thread I pointed out that /media gets mounted with a tmpfs over it. If you want your directories to stop "disappearing", mask the /lib/systemd/systemd/media.mount unit.

I tried this like you described on https://bbs.archlinux.org/viewtopic.php … 56#p948656

# systemctl stop media.mount
# ln -s /dev/null /etc/systemd/system/local-fs.target.wants/media.mount
# kill -1 1

After reboot the overlay was still created again.

So I also masked media.mount in /lib/. media.mount looks now like:

 ls -l  /{lib,etc}/systemd/system/local-fs.target.wants/media.mount                                                                                   
lrwxrwxrwx 1 root root 9 29. Jun 19:24 /etc/systemd/system/local-fs.target.wants/media.mount -> /dev/null                                                                        
lrwxrwxrwx 1 root root 9 29. Jun 20:51 /lib/systemd/system/local-fs.target.wants/media.mount -> /dev/null 

So everything seems to be ok at this side. The overlay ist still created each time I boot.
When i do a systemctl dump  and look for the media.mount unit I still seem to point to the correct file

-> Unit media.mount:
    Description: Media Directory
    Instance: n/a
    Unit Load State: loaded
    Unit Active State: active
    Inactive Exit Timestamp: Wed, 29 Jun 2011 21:09:57 +0200
    Active Enter Timestamp: Wed, 29 Jun 2011 21:09:57 +0200
    Active Exit Timestamp: n/a
    Inactive Enter Timestamp: n/a
    GC Check Good: yes
    Need Daemon Reload: no
    Name: media.mount
    Fragment Path: /lib/systemd/system/media.mount
    Condition Timestamp: Wed, 29 Jun 2011 21:09:57 +0200
    Condition Result: yes
    Requires: systemd-logger.socket
    Requires: -.mount
    RequiredBy: media-data.mount
    WantedBy: local-fs.target
    Conflicts: umount.target
    Before: local-fs.target
    Before: media-data.mount
    Before: umount.target
    After: systemd-logger.socket
    After: -.mount
    References: local-fs.target
    References: systemd-logger.socket
    References: umount.target
    References: -.mount
    ReferencedBy: local-fs.target
    ReferencedBy: media-data.mount
    StopWhenUnneeded: no
    RefuseManualStart: no
    RefuseManualStop: no
    DefaultDependencies: yes
    OnFailureIsolate: no
    IgnoreOnIsolate: yes
    IgnoreOnSnapshot: no
    ControlGroup: cpu:/system/media.mount
    ControlGroup: name=systemd:/system/media.mount
    Mount State: mounted
    Where: /media
    What: tmpfs
    File System Type: tmpfs
    Options: rw,nosuid,nodev,noexec,relatime,rw,mode=755
    From /etc/fstab: no
    From /proc/self/mountinfo: yes
    From fragment: yes
    DirectoryMode: 0755
    UMask: 0002
    WorkingDirectory: /
    RootDirectory: /
    NonBlocking: no
    PrivateTmp: no
    StandardInput: null
    StandardOutput: kmsg
    StandardError: inherit
    SyslogFacility: daemon
    SyslogLevel: info
    KillMode: control-group
    KillSignal: SIGTERM
    SendSIGKILL: yes

So don't know why this is not working here.  I will try the tmpfs method next.

It actually stopped working for me either, the symlink is still there but media.mount is started on boot. The tmpfs way works flawless.
I guess it stopped working after upgrading to systemd 29 but i didn't test that.

Offline

#811 2011-06-29 21:16:11

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

Re: systemd: Yet Another Init Replacement

Works for me. Had to change the symlink to mask the unit from /etc/systemd/system instead of from the wants dir.

Offline

#812 2011-06-30 01:56:42

yvonney
Member
Registered: 2008-06-11
Posts: 671

Re: systemd: Yet Another Init Replacement

UPDATE COMMENT:  [errors after massive fsck errors all fixed with tons of lost files]
just after grub menu: 1 second flash of 2 lines:
"error: out of partition"
"error: no suitable command found"

after bootup: unable to do much at prompt
"unknown teminal "linux"

during bootup after udev rules loading

"syslog-ng line 7 command not found"


yep. my system crapped out bigtime. Been many season since any issues so looking forward to redo or fix.

So: could anyone tell me what to post from my logs. I see a flashing 2 lines just after grub menu.
Something about tty? dunno quite yet. Truly sorry to appear so slack her, just juggling a lot at the moment
and totally down running from live CD here.

right, so ... I believe it's the updates from today (and i do run all testing as well)systemd-arch-unit
systemd   and the systemd-arch-unit   from today and earlier.

I rebooted. more fsck fixes and lost files than I've EVER seen. and it boots up though tons messed up.
I should read logs? and post... what?

thanks. all sincerely good fun though. a bit surprised and you know the one. I was just thinking today how
fortune I'd been and how solid all the testing stuff had been with my particular system.    hehehe

uhhhh.... broken.

Last edited by yvonney (2011-06-30 02:31:21)

Offline

#813 2011-07-04 22:38:59

Viper_Scull
Member
From: London, UK
Registered: 2011-01-15
Posts: 153

Re: systemd: Yet Another Init Replacement

I'm trying to get rid of rc.conf for good. The only thing i keep is network configuration. What would be the native way of systemd of configuring the network?


Athlon II X4 620 + Gigabyte 785GPM-UD2H + 4GB DDR3 + SSD OCZ Vertex2 60GB

Archlinux x86_64 + Openbox

Offline

#814 2011-07-05 00:42:30

Maki
Member
From: Skopje, Macedonia
Registered: 2007-10-16
Posts: 353
Website

Re: systemd: Yet Another Init Replacement

Viper_Scull wrote:

I'm trying to get rid of rc.conf for good. The only thing i keep is network configuration. What would be the native way of systemd of configuring the network?

systemd does not configure your network for you, try ifplugd or wicd. and keep rc.conf, don't nuke it and don't delete the daemons line, just disable the arch-units in systemd


If it ain't broke, broke it then fix it.

Offline

#815 2011-07-05 06:40:29

lymphatik
Member
From: Somewhere else
Registered: 2009-03-07
Posts: 119

Re: systemd: Yet Another Init Replacement

Maki wrote:
Viper_Scull wrote:

I'm trying to get rid of rc.conf for good. The only thing i keep is network configuration. What would be the native way of systemd of configuring the network?

systemd does not configure your network for you, try ifplugd or wicd. and keep rc.conf, don't nuke it and don't delete the daemons line, just disable the arch-units in systemd

You are actually wrong. This will do the trick of course you will have to change the ip and gateway and interface to suit your need.

[Unit]
Description=Network Connectivity
Before=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/ifconfig eth0 10.1.1.3
ExecStart=/sbin/route add default gw 10.1.1.254
ExecStop=/sbin/ifconfig eth0 down

[Install]
WantedBy=multi-user.target

Last edited by lymphatik (2011-07-05 06:40:54)

Offline

#816 2011-07-05 07:24:59

sidneyk
Member
From: Bonner Springs, KS. USA
Registered: 2011-04-22
Posts: 129

Re: systemd: Yet Another Init Replacement

Viper_Scull wrote:

I'm trying to get rid of rc.conf for good. The only thing i keep is network configuration. What would be the native way of systemd of configuring the network?

If you are using Gnome you can install networkmanager and network-manager-applet and enable the service unit ( sudo systemctl enable NetworkManager.service ) and it works fine with auto configured internet connection. If you need some other thing you can configure networkmanager for it and there are also different plugins available for pppoe vpn, etc. This won't give you a network if you boot into recovery mode (I don't know if one was present under the normal way or not) but will give you a network for Gnome or your tty's, at least a working internet connection. I'm not using rc.conf and haven't for a few weeks now. You have to edit or create and enable the native service units for hostname, locale.conf, vconsole.conf, etc. as outlined in the wiki and you have to enable appropriate service units for any of the daemons you were using in rc.conf. I'm running everyday rc.conf free with systemd and Gnome 3 - Gnome Shell and have even uninstalled the initscripts.

Last edited by sidneyk (2011-07-05 07:26:25)

Offline

#817 2011-07-05 15:15:55

Viper_Scull
Member
From: London, UK
Registered: 2011-01-15
Posts: 153

Re: systemd: Yet Another Init Replacement

sidneyk wrote:
Viper_Scull wrote:

I'm trying to get rid of rc.conf for good. The only thing i keep is network configuration. What would be the native way of systemd of configuring the network?

If you are using Gnome you can install networkmanager and network-manager-applet and enable the service unit ( sudo systemctl enable NetworkManager.service ) and it works fine with auto configured internet connection. If you need some other thing you can configure networkmanager for it and there are also different plugins available for pppoe vpn, etc. This won't give you a network if you boot into recovery mode (I don't know if one was present under the normal way or not) but will give you a network for Gnome or your tty's, at least a working internet connection. I'm not using rc.conf and haven't for a few weeks now. You have to edit or create and enable the native service units for hostname, locale.conf, vconsole.conf, etc. as outlined in the wiki and you have to enable appropriate service units for any of the daemons you were using in rc.conf. I'm running everyday rc.conf free with systemd and Gnome 3 - Gnome Shell and have even uninstalled the initscripts.

I'm using Xfce or Wmfs. The thing is i did not want Networkmanager, wicd or anything like that controlling  my network. I was using network.service.

lympathik wrote:

You are actually wrong. This will do the trick of course you will have to change the ip and gateway and interface to suit your need.
[Unit]
Description=Network Connectivity
Before=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/ifconfig eth0 10.1.1.3
ExecStart=/sbin/route add default gw 10.1.1.254
ExecStop=/sbin/ifconfig eth0 down

[Install]
WantedBy=multi-user.target

Thanks. I've modified the service so it could use iproute2 instead of the deprecated nettools. I've also disabled network.service, since it loads rc.conf and try to configure the net from it. I've deleted rc.conf and everything seems to be working just fine.
So this is the service:

[Unit]
Description=Network Connectivity
Before=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/ip link set eth0 up ; /sbin/ip addr add 192.168.1.2/24 dev eth0 ; /sbin/ip route add default via 192.168.1.1
ExecStop=/sbin/ip link set eth0 down

[Install]
WantedBy=multi-user.target

Last edited by Viper_Scull (2011-07-08 12:41:48)


Athlon II X4 620 + Gigabyte 785GPM-UD2H + 4GB DDR3 + SSD OCZ Vertex2 60GB

Archlinux x86_64 + Openbox

Offline

#818 2011-07-05 17:58:35

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

Re: systemd: Yet Another Init Replacement

Multiple ExecStart statements have no guarantee of ordering -- they're all called as fork/exec in parallel. You'd be better off serializing....

ExecStart=ip link set eth0 up ; ip addr add .... ; ip route ...

Note that the space around the semi-colon is important. It needs to be its own 'word'.

Last edited by falconindy (2011-07-05 17:59:01)

Offline

#819 2011-07-05 18:30:09

Viper_Scull
Member
From: London, UK
Registered: 2011-01-15
Posts: 153

Re: systemd: Yet Another Init Replacement

falconindy wrote:

Multiple ExecStart statements have no guarantee of ordering -- they're all called as fork/exec in parallel. You'd be better off serializing....

ExecStart=ip link set eth0 up ; ip addr add .... ; ip route ...

Note that the space around the semi-colon is important. It needs to be its own 'word'.

That's an important point, cause ip route needs the link to be up.

Changed now. Thank you.

Last edited by Viper_Scull (2011-07-05 18:30:35)


Athlon II X4 620 + Gigabyte 785GPM-UD2H + 4GB DDR3 + SSD OCZ Vertex2 60GB

Archlinux x86_64 + Openbox

Offline

#820 2011-07-05 19:22:07

el mariachi
Member
Registered: 2007-11-30
Posts: 595

Re: systemd: Yet Another Init Replacement

Disregard this post. There was no problem after all.

Last edited by el mariachi (2011-07-05 22:58:09)

Offline

#821 2011-07-06 07:29:39

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

Re: systemd: Yet Another Init Replacement

falconindy wrote:

Multiple ExecStart statements have no guarantee of ordering -- they're all called as fork/exec in parallel. You'd be better off serializing....

ExecStart=ip link set eth0 up ; ip addr add .... ; ip route ....

Is it possible to implement wpasupplicant?

[Unit]
Description=Network Connectivity
Before=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=ip link set wlan0 up ; ip addr add 10.252.82.10/24 dev wlan0 ; ip route add default via 10.252.82.1
ExecStop=ip link set wlan0 down

[Install]
WantedBy=multi-user.target.


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

Offline

#822 2011-07-06 07:37:48

stefano.facchini
Member
Registered: 2010-11-12
Posts: 24

Re: systemd: Yet Another Init Replacement

falconindy wrote:

systemd 29 tagged. Plymouth users will want to grab units from the sourceball or git as I'm no longer distributing them with the package. Sorry.

Hi,
I installed plymouth-git package from the AUR and followed the instructions on the Wiki page, which gave me a correct splash image during the boot, but not while rebooting or halting. I tried to manually install the systemd service files (plymouth*.service, systemd-ask-for-password-plymouth.*) related to plymouth and enable them, but with no effect. Could you please explain how to use them (and why they are not part of the systemd package!)..
thanks

Offline

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

Maki
Member
From: Skopje, Macedonia
Registered: 2007-10-16
Posts: 353
Website

Re: systemd: Yet Another Init Replacement

Ever since i disabled the arch compatibility units bootup hangs at a line that prints something about starting random seeds. here is the bootchart http://ompldr.org/vOWRudA/plot.svg


If it ain't broke, broke it then fix it.

Offline

#824 2011-07-06 14:58:30

crabman
Member
Registered: 2010-08-12
Posts: 30

Re: systemd: Yet Another Init Replacement

I noticed that systemd starts the displaymanager even if fsck is running one of its "long" checks. Thats annoying because i cant see fscks progress or skip it. Is there a way to make systemd wait until fsck is done only when its checking the whole disk?

I use comment=systemd.automount for my /home partition in fstab

crabman

Offline

#825 2011-07-06 16:27:09

lymphatik
Member
From: Somewhere else
Registered: 2009-03-07
Posts: 119

Re: systemd: Yet Another Init Replacement

ron9 wrote:
falconindy wrote:

Multiple ExecStart statements have no guarantee of ordering -- they're all called as fork/exec in parallel. You'd be better off serializing....

ExecStart=ip link set eth0 up ; ip addr add .... ; ip route ....

Is it possible to implement wpasupplicant?

[Unit]
Description=Network Connectivity
Before=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=ip link set wlan0 up ; ip addr add 10.252.82.10/24 dev wlan0 ; ip route add default via 10.252.82.1
ExecStop=ip link set wlan0 down

[Install]
WantedBy=multi-user.target.

I do not see why not just add the required command line in Execstart and it should work

Offline

Board footer

Powered by FluxBB