You are not logged in.

#1076 2011-12-31 13:36:40

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

Re: systemd: Yet Another Init Replacement

I've found a weird thing on my native systemd config.

I dont have initscripts-systemd installed. I thought i didnt have initscripts installed but actually i did, so i removed it cause i thought i was not using it. Now comes the weird thing. When i remove initscripts all the locale variables are set to POSIX (except LANG and LC_ALL, which are not set). After reinstalling initscripts everything went back to normal, and variables are set as indicated in locale.conf

Is systemd using some script of initscripts to set locale variables?

Last edited by Viper_Scull (2011-12-31 14:05:50)


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

Archlinux x86_64 + Openbox

Offline

#1077 2011-12-31 13:41:56

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

Re: systemd: Yet Another Init Replacement


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

#1078 2011-12-31 14:01:00

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

Re: systemd: Yet Another Init Replacement

I dont see your point. Can you elaborate?


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

Archlinux x86_64 + Openbox

Offline

#1079 2011-12-31 14:42:19

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

Re: systemd: Yet Another Init Replacement

tomegun wrote:

Cups does not support socket activation (yet). The socket unit is not in systemd-arch-units as far as I can tell.

According to Lennart's blog "systemd for Developers" cups is ready for socket activation.

# http://0pointer.de/blog/projects/socket … tion2.html

I used the cups socket and service unit from Lennart's blog, and it works as expected.

Problem is that cups web interface timeout with error: Unable to bind socket for address 0.0.0.0:631 - Address already in use.

Last edited by ron9 (2011-12-31 14:47:32)


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

Offline

#1080 2011-12-31 14:45:18

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

Re: systemd: Yet Another Init Replacement

Viper_Scull wrote:

When i remove initscripts all the locale variables are set to POSIX (except LANG and LC_ALL, which are not set). After reinstalling initscripts everything went back to normal, and variables are set as indicated in locale.conf

Systemd will set the locale just fine without initscripts installed. However, if something (agetty/login?) unsets it, having initscripts around will help as /etc/profile.d/locale.sh (owned by initscripts) will set the locale vars based on /etc/locale.conf.

Offline

#1081 2011-12-31 14:52:59

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

Re: systemd: Yet Another Init Replacement

ron9 wrote:

According to Lennart's blog "systemd for Developers" cups is ready for socket activation.

# http://0pointer.de/blog/projects/socket … tion2.html

I used the cups socket and service unit from Lennart's blog, and it works as expected.

Problem is that cups web interface timeout with error: Unable to bind socket for address 0.0.0.0:631 - Address already in use.

.

What do you mean by "works as expected"?

Did you apply Lennart's patch to cups?

The error you are getting indicates that systemd is listening on the socket and passes it to cups, but cups is unable to accept it and tries to open it from scratch.

Offline

#1082 2011-12-31 15:14:14

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

Re: systemd: Yet Another Init Replacement

tomegun wrote:

What do you mean by "works as expected"?

After startup cups.socket is listening and start cups.service first when it is triggered.

Did you apply Lennart's patch to cups?

I thought the patch was implemented since the blog is from the July 5

The error you are getting indicates that systemd is listening on the socket and passes it to cups, but cups is unable to accept it and tries to open it from scratch.

OK. Then it is not working as expected :-(
I dont now how to add a patch so I have to wait until it is ready...

.

Last edited by ron9 (2011-12-31 15:22:39)


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

Offline

#1083 2011-12-31 15:31:52

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

Re: systemd: Yet Another Init Replacement

ron9 wrote:
tomegun wrote:

What do you mean by "works as expected"?

After startup cups.socket is listening and start cups.service first when it is triggered.

Ah, yeah. That will always happen no matter what the service is. It does not mean that the service is able to use the socket that is passed to it.

Did you apply Lennart's patch to cups?

I thought the patch was implemented since the blog is from the July 5

Not as far as I know. I think the patch as described in the blogpost would probably not go in as it required some files to be copied into the cups sources. There is now a shared lib that might make it more palatable.

Offline

#1084 2011-12-31 16:17:37

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

Re: systemd: Yet Another Init Replacement

The cups/systemd bug report (with patches): http://cups.org/str.php?L3917


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

Offline

#1085 2012-01-04 23:08:25

wwmm
Member
From: Rio de Janeiro, Brazil
Registered: 2010-08-14
Posts: 28

Re: systemd: Yet Another Init Replacement

Hello,

I don´t know if this was already discussed here but I will post my experience because it could be useful to somebody. While I was trying to enable the force feedback of my xbox 360 controller I found out that I hadn't write permission on the devices under /dev/input/event*. After much time I decided to boot with systemd disabled and the problem was fixed. As this is not a real solution I googled a little and found out the source of the problem. I had to add the line :

"session optional pam_systemd.so"

to the file  "/etc/pam.d/kde-np".

Now I see that this instruction is on systemd wiki page, but maybe it would be good to mention there that the above line MUST be added to have write access to joysticks, what is necessary to enable force feedback.

Last edited by wwmm (2012-01-04 23:09:33)

Offline

#1086 2012-01-04 23:13:48

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

Re: systemd: Yet Another Init Replacement

wwmm wrote:

I found out that I hadn't write permission on the devices under /dev/input/event*. [...] I googled a little and found out the source of the problem. I had to add the line :

"session optional pam_systemd.so"

to the file  "/etc/pam.d/kde-np".

Now I see that this instruction is on systemd wiki page, but maybe it would be good to mention there that the above line MUST be added to have write access to joysticks, what is necessary to enable force feedback.

This line needs to be added to kde/gdm/'whatever controls your session' in order to get permissions on any device nodes (ACL). Consolekit disables itself when systemd is running, so systemd needs to take over this job.

Offline

#1087 2012-01-05 21:41:11

ImNtReal
Member
Registered: 2011-09-26
Posts: 17

Re: systemd: Yet Another Init Replacement

I've been struggling with getting systemd functioning in a bit of what you might call a niche setup.  I have a Drobo with two LUNs that I'm currently using, the third isn't in use:

# drobom status
/dev/sdb:/dev/sdc:/dev/sdd - Drobo disk pack 66% full - ([], 0)

For some reason, using fstab works fine at boot:

/dev/sdb1    /mnt/drobo0 ext3 defaults,noatime,nodiratime,comment=systemd.mount 0 0
/dev/sdc1    /mnt/drobo1 ext3 defaults,noatime,nodiratime,comment=systemd.mount 0 0

Unfortuneately, this doesn't work at boot:

# cat /lib/systemd/system/mnt-drobo0.mount
[Unit]
Description=/mnt/drobo0
Requires=systemd-stdout-syslog-bridge.socket -.mount
Conflicts=umount.target
Before=umount.target local-fs.target raid.mount
After=systemd-stdout-syslog-bridge.socket local-fs-pre.target -.mount

[Mount]
Where=/mnt/drobo0
What=/dev/sdb1
Options=rw,noatime,nodiratime,rw,errors=continue,barrier=1,data=ordered
Type=ext3

# systemctl status mnt-drobo0.mount
mnt-drobo0.mount - /mnt/drobo0
      Loaded: loaded (/lib/systemd/system/mnt-drobo0.mount; static)
      Active: inactive (dead)
       Where: /mnt/drobo0
        What: /dev/sdb1
      CGroup: name=systemd:/system/mnt-drobo0.mount

But, after booting:

# systemctl start mnt-drobo0.mount
# systemctl status mnt-drobo0.mount
mnt-drobo0.mount - /mnt/drobo0
      Loaded: loaded (/lib/systemd/system/mnt-drobo0.mount; static)
      Active: active (mounted) since Thu, 05 Jan 2012 16:38:04 -0500; 7s ago
       Where: /mnt/drobo0
        What: /dev/sdb1
     Process: 1226 ExecMount=/bin/mount /dev/sdb1 /mnt/drobo0 -t ext3 -o rw,noatime,nodiratime,rw,errors=continue,barrier=1,data=ordered (code=exited, status=0/SUCCESS)
      CGroup: name=systemd:/system/mnt-drobo0.mount

The only things I can think of are either I have configured this wrong, or systemd trys to mount it before the Drobo has initalized when using the unit files.  Does anyone have any ideas about this?  Thanks.

Offline

#1088 2012-01-05 22:18:03

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

Re: systemd: Yet Another Init Replacement

I recommend that you put custom services/mount/whatever files in /etc/systemd/system, rather than /lib/systemd/system.

Also, have you enabled mnt-drobo0.mount (et al)? The status output suggests to me that you haven't.

# systemctl enable mnt-drobo0.mount

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

#1089 2012-01-06 15:28:34

ImNtReal
Member
Registered: 2011-09-26
Posts: 17

Re: systemd: Yet Another Init Replacement

WorMzy wrote:

I recommend that you put custom services/mount/whatever files in /etc/systemd/system, rather than /lib/systemd/system.

Also, have you enabled mnt-drobo0.mount (et al)? The status output suggests to me that you haven't.

# systemctl enable mnt-drobo0.mount

I'll go ahead and get them moved.  I should have really been keeping them there from the beginning.

Should I have an [Install] section in these?

# systemctl is-enabled mnt-drobo0.mount
static
# systemctl enable mnt-drobo0.mount
Warning: unit files do not carry install information. No operation executed.

Offline

#1090 2012-01-06 16:42:57

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

Re: systemd: Yet Another Init Replacement

You can do if you want, none of the standard .mount files have one for some reason, but the man pages say that it's fine for any systemd unit files to have one.

Alternatively, you could just manually create a symlink to the .mount files in /etc/systemd/system/local-fs.target.wants.


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

#1091 2012-01-06 19:34:33

ImNtReal
Member
Registered: 2011-09-26
Posts: 17

Re: systemd: Yet Another Init Replacement

After a reboot:

# systemctl status mnt-drobo0.mount
mnt-drobo0.mount - /mnt/drobo0
	  Loaded: loaded (/etc/systemd/system/mnt-drobo0.mount; enabled)
	  Active: failed since Fri, 06 Jan 2012 14:14:34 -0500; 1min 5s ago
	   Where: /mnt/drobo0
	    What: /dev/sdb1
	 Process: 462 ExecMount=/bin/mount /dev/sdb1 /mnt/drobo0 -t ext3 -o rw,noatime,nodiratime,rw,errors=continue,barrier=1,data=ordered (code=exited, status=32)
	  CGroup: name=systemd:/system/mnt-drobo0.mount

Then, I tried a reboot using systemctl, and it worked.  Maybe that's the trick.  Now, to see if I can get my AuFS mount working on top of it.  smile

Offline

#1092 2012-01-06 20:21:29

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

Re: systemd: Yet Another Init Replacement

If you frequently find that the mount fails, you might want to add drobo.service (I'm guessing that's what it's called, not in a position to check) to the mount's "After" list; then it won't try to mount the filesystems before the service has initialized.


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

#1093 2012-01-06 23:43:38

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

Re: systemd: Yet Another Init Replacement

ImNtReal wrote:

The only things I can think of are either I have configured this wrong, or systemd trys to mount it before the Drobo has initalized when using the unit files.

I don't now your usercase, but have you consider automount. Mount will then take place first when you trigger your mountpoint drobo0.

http://0pointer.de/public/systemd-man/systemd.automount.html

I automount boot, home and a windows homeserver and spare some boottime. I have tried to make unit files for automounting, but with no luck so far.
Comment=systemd.automount in fstab works fine.


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

Offline

#1094 2012-01-09 16:32:28

Blind
Member
From: Desert mountain
Registered: 2005-02-06
Posts: 386

Re: systemd: Yet Another Init Replacement

Viper_Scull wrote:
Viper_Scull wrote:

Console System Startup Loggin status is failed:

console-kit-log-system-start.service - Console System Startup Logging
      Loaded: loaded (/lib/systemd/system/console-kit-log-system-start.service)
      Active: failed since Mon, 20 Jun 2011 15:19:11 +0200; 7min ago
     Process: 302 ExecStart=/usr/sbin/ck-log-system-start (code=exited, status=1/FAILURE)
      CGroup: name=systemd:/system/console-kit-log-system-start.service

However if i restart the service:

console-kit-log-system-start.service - Console System Startup Logging
      Loaded: loaded (/lib/systemd/system/console-kit-log-system-start.service)
      Active: active (exited) since Mon, 20 Jun 2011 15:27:57 +0200; 1s ago
     Process: 1173 ExecStart=/usr/sbin/ck-log-system-start (code=exited, status=0/SUCCESS)
      CGroup: name=systemd:/system/console-kit-log-system-start.service

Could it be anything related to the dependencies?

[Unit]
Description=Console System Startup Logging
DefaultDependencies=no
After=sysinit.target
Before=shutdown.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/ck-log-system-start
RemainAfterExit=yes

Any comments someone?

I think this could be the problem but i'm not sure. I have /var/log to be mounted as tmpfs. Maybe the service is called before that happens. What can i add to the field After in the service unit to make it wait for /var/log to be mounted in RAM?

Hi,

I am having the exact same problem (and I also mounted /var/log with tmpfs). Have you found a remedy to this problem? I am fairly new to systemd, and so far the only thing I have tried was to modify the "After=" field to also include local_fs.service. That did not do the trick, as far as I can tell.

Thanks!

Offline

#1095 2012-01-11 12:03:13

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

Re: systemd: Yet Another Init Replacement

Blind wrote:

Hi,

I am having the exact same problem (and I also mounted /var/log with tmpfs). Have you found a remedy to this problem? I am fairly new to systemd, and so far the only thing I have tried was to modify the "After=" field to also include local_fs.service. That did not do the trick, as far as I can tell.

Thanks!

I haven't found any solution yet. Still failing.

Console-kit-log-system-start.service has to start after sysinit.target which is reached after local-fs.target so indeed that change shouldn't affect on anything.

Dmesg prints

<28>systemd-tmpfiles[277]: Two or more conflicting lines for /tmp configured, ignoring.
<28>systemd-tmpfiles[277]: Two or more conflicting lines for /tmp/.X11-unix configured, ignoring.
<28>systemd-tmpfiles[277]: Two or more conflicting lines for /tmp/.ICE-unix configured, ignoring.
<28>systemd-tmpfiles[277]: Two or more conflicting lines for /tmp/.XIM-unix configured, ignoring.
<28>systemd-tmpfiles[277]: Two or more conflicting lines for /tmp/.font-unix configured, ignoring.
<28>systemd-tmpfiles[277]: Two or more conflicting lines for /tmp/.Test-unix configured, ignoring.
<30>ck-log-system-start[281]: ** (process:281): WARNING **: Couldn't create log file /var/log/ConsoleKit/history (No such file or directory
<29>systemd[1]: console-kit-log-system-start.service: main process exited, code=exited, status=1
<29>systemd[1]: Unit console-kit-log-system-start.service entered failed state.

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

Archlinux x86_64 + Openbox

Offline

#1096 2012-01-11 15:54:31

ImNtReal
Member
Registered: 2011-09-26
Posts: 17

Re: systemd: Yet Another Init Replacement

ron9 wrote:
ImNtReal wrote:

The only things I can think of are either I have configured this wrong, or systemd trys to mount it before the Drobo has initalized when using the unit files.

I don't now your usercase, but have you consider automount. Mount will then take place first when you trigger your mountpoint drobo0.

The issue with automount is I also want to mount the two LUNs into one location using AuFS.  This location includes /home.  I think there may still be some timing issues, so I may need to come up with a way to detect that it is initialized, and hold the mounting until that point.

Offline

#1097 2012-01-13 03:38:32

mwknowles92
Member
Registered: 2010-08-28
Posts: 19

Re: systemd: Yet Another Init Replacement

I've been getting some slightly annoying messages while booting.  It doesn't cause any problems, but I still wonder why these errors are showing up.

[    1.771982] EXT4-fs (sda5): couldn't mount as ext2 due to feature incompatibilities
[    1.727911] EXT4-fs (sda5): couldn't mount as ext3 due to feature incompatibilities

I haven't been able to find anything on google yet, any ideas what's going on?

Offline

#1098 2012-01-13 03:53:11

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

Re: systemd: Yet Another Init Replacement

Missing entry in your fstab and mount is guessing?

Offline

#1099 2012-01-13 18:36:53

mwknowles92
Member
Registered: 2010-08-28
Posts: 19

Re: systemd: Yet Another Init Replacement

No, I have sda5 in there and explicitly listed as an ext4 partition.  Here's the relevant line:

/dev/sda5 / ext4 defaults,noatime 0 1

Offline

#1100 2012-01-13 21:05:31

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

Re: systemd: Yet Another Init Replacement


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

Offline

Board footer

Powered by FluxBB