systemd: Yet Another Init Replacement

Viper_Scull · 2011-01-28 08:07:26

Now i think i found the problem, but i dont know why.

I had MOD_AUTOLOAD in rc.conf set as no, and i specified them manually. I've changed to autoload=yes and the system booted perfectly. I'm gonna keep testing it.

I tried to update mkinitcpio(x86_64) from testing, but it looks there is some kind of problem with util-linux-ng-git:

bary /proc $ pacman -U ftp://ftp.gtlib.gatech.edu/pub/linux/di … pkg.tar.xz
Password:
mkinitcpio-0.6.8-1-any 17.9K 57.2K/s 00:00:00 [##########################################] 100%
resolving dependencies...
looking for inter-conflicts...
:: util-linux-ng and util-linux-ng-git are in conflict (linux32). Remove util-linux-ng-git? [y/N] n
error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)
:: util-linux-ng and util-linux-ng-git are in conflict (linux32)

Last edited by Viper_Scull (2011-01-28 09:34:14)

falconindy · 2011-01-28 11:07:44

-Rd util-linux-ng-git and install util-linux-git. This is my fault, but util-linux is a mess because the project's decided to rename itself yet again (back to its original name).

Viper_Scull · 2011-01-28 15:52:08

Thanks, that did it.

Looks like systemd ignores manually specified modules to load. I'm using modprobe in rc.local for the time being to load powernow,cpu_freq, etc
Seems to be ignoring the option ipv6.disable=1 when loading the kernel, cause i can see the module ipv6 loaded (it does not happen with normal init booting)

Everything else looks stable so far, except two times that it took it like 25 secs to restart . I can't see a big improvement in booting speed, because for now i dont have many services at start yet, and on the SSD both starts are very fast, but it looks very promising.

Last edited by Viper_Scull (2011-01-28 16:03:45)

falconindy · 2011-01-28 16:13:18

You shouldn't be putting modprobe options in /etc/rc.local. They belong in /etc/modprobe.d where modprobe reads from. Those options are guaranteed to be read. Regardless, if you want/need to use /etc/rc.local for other stuff, you'll need to do `systemctl enable rc-local.service`.

Viper_Scull · 2011-02-04 16:30:32

Posted by mistake Sorry i bumped it for nothing

Last edited by Viper_Scull (2011-02-04 16:40:36)

denisfalqueto · 2011-02-06 01:44:16

I was fixing some problems with the hardware clock of my machine and looked over ntpd.service, which is provided by systemd-arch-units. It contains the following line:

ExecStart=/usr/bin/ntpd -n -u ntp:ntp $NTPD_ARGS

The option -u ntp:ntp forces one to use a non root user. Indeed, it is a good thing, but I don't think that it should be forced upon the user without it being conscious of it. The wiki page for ntpd instructs on how to proceed to use it with another user, by informing it in /etc/conf.d/ntp-client.conf. So, I think that ntpd.service should not contain an explicit configuration for the user.

Zom · 2011-02-06 04:57:38

denisfalqueto wrote:

I was fixing some problems with the hardware clock of my machine and looked over ntpd.service, which is provided by systemd-arch-units. It contains the following line:
ExecStart=/usr/bin/ntpd -n -u ntp:ntp $NTPD_ARGS
The option -u ntp:ntp forces one to use a non root user. Indeed, it is a good thing, but I don't think that it should be forced upon the user without it being conscious of it. The wiki page for ntpd instructs on how to proceed to use it with another user, by informing it in /etc/conf.d/ntp-client.conf. So, I think that ntpd.service should not contain an explicit configuration for the user.

Stuff like mpd already does this by default. Why shouldn't mpd?

Last edited by Zom (2011-02-06 04:58:24)

denisfalqueto · 2011-02-06 05:27:01

Basically, because it is not what the script /etc/rc.d/ntpd does. And, in my case, I didn't have a special user for ntpd, so it just wouldn't work. I had to spend some time figuring out what happened (I'm not complaining). If it just respected what is in /etc/conf.d/ntp-client.conf, there would be a better approach. If someone wants to use a special user for ntp, he'll know it and create a user/group for that purpose. Those who don't want a special user, will have it working too.

falconindy · 2011-02-06 05:41:44

denisfalqueto wrote:

Basically, because it is not what the script /etc/rc.d/ntpd does. And, in my case, I didn't have a special user for ntpd, so it just wouldn't work. I had to spend some time figuring out what happened (I'm not complaining). If it just respected what is in /etc/conf.d/ntp-client.conf, there would be a better approach. If someone wants to use a special user for ntp, he'll know it and create a user/group for that purpose. Those who don't want a special user, will have it working too.

I agree. it's changed.

ngoonee · 2011-02-07 15:24:37

Please revert/modify /lib/systemd/system/syslog-ng.service to the old version (January, given below). The current git version hangs my bootup process.

[Unit]
Description=System Logger Daemon
DefaultDependencies=no
Conflicts=shutdown.target
Requires=local-fs.target
After=local-fs.target
Before=syslog.target

[Service]
ExecStart=/usr/sbin/syslog-ng -F
ExecReload=/bin/kill -HUP $MAINPID
Restart=always

[Install]
WantedBy=syslog.target

Now that I think about it, its either related to now using syslog.socket or being wantedby graphical.target where it was previously syslog.target. Whichever is the case, please let me know if I can help debug.

falconindy · 2011-02-08 01:50:05

The socket isn't used and syslog-ng was never wanted by graphical.target. I'm not sure what is the actual cause of your boot issue but you're the first to report such a problem with this particular unit file. I've got 3 systems booting just fine with the new syslog-ng unit file.

You're not by chance running a 2.6.38 rc, are you?

Last edited by falconindy (2011-02-08 01:50:56)

ngoonee · 2011-02-08 02:25:31

falconindy wrote:

The socket isn't used and syslog-ng was never wanted by graphical.target. I'm not sure what is the actual cause of your boot issue but you're the first to report such a problem with this particular unit file. I've got 3 systems booting just fine with the new syslog-ng unit file.
You're not by chance running a 2.6.38 rc, are you?

Nope, running [testing] but that's it. Same symptoms on my -ice kernel and the stock Arch kernel.

The syslog-ng unit file I pasted up is the previous one, the current one is wantedby multi-user.target, sorry. When I boot up it hangs at 'retrying udev', but I can get it to continue booting by Alt-SysRq-E to kill the process. The system doesn't have udev after that though, so things like thumb drives don't get mounted.

What information can I provide? The changes I've made is adding gdm.service, net-auto-{wired,wireless}-service, and sshd.socket with a modified ListenStream.

falconindy · 2011-02-08 11:14:04

boot with debugging enabled -- add systemd.log_level=debug to your kernel cmdline.

ngoonee · 2011-02-08 13:05:04

falconindy wrote:

boot with debugging enabled -- add systemd.log_level=debug to your kernel cmdline.

Did that, encountered the problem (I think).

The thing is that previously what would happen is that boot just cold stops. This time I waited for it to do that (as the logs flew by), then it started booting again. However once gdm started up it auto-logged in then X died and restarted, so autologin again. Three times before I just killed it and got my normal login prompt.

I assume everything.log has what's important? I have about 2.6k lines from this particular boot... anything I should look out for?

falconindy · 2011-02-08 14:10:47

Are you running arch-daemons.target? I've noticed that it tends to create a fairly long pause on boot, particularly if you're using something like net-profiles, since the units are created as type Forking and systemd won't continue until they're loaded. I really don't think this is related to the syslog-ng change.

ngoonee · 2011-02-08 14:27:14

falconindy wrote:

Are you running arch-daemons.target? I've noticed that it tends to create a fairly long pause on boot, particularly if you're using something like net-profiles, since the units are created as type Forking and systemd won't continue until they're loaded. I really don't think this is related to the syslog-ng change.

I did a diff on systemd-arch-units contents, the only things which changed were ntpd.service and syslog-ng.service. Also sshdgenkeys was moved around a bit and lvm2-tmpfiles.conf and uptimed.service was added.

I reverted to the previous version and made the ntpd.service change (not using user ntp:ntp), no problem. I made the changes to syslog-ng.service and the problem appeared. And yes I'm running arch-daemons.target, should I not be? I don't have net-profiles, instead I have net-auto-wired and net-auto-wireless (both of which I have created .service files for already). Here's my DAEMONS array just in case:-

DAEMONS=(dbus @laptop-mode @alsa @syslog-ng !net-profiles !wicd !network @net-auto-wireless @net-auto-wired !networkmanager @fcron @sensors @mpd @dovecot @hibernate-cleanup @bluetooth @cups @irqbalance !sshd)

falconindy · 2011-02-08 15:03:40

Foolish question -- did you enable syslog-ng.service via systemctl after the unit change? I didn't personally make the changes to the unit, and I wasn't a huge fan of said changes... but I suppose I have to deal with them now X.X

edit: ding, 1000 posts.

Last edited by falconindy (2011-02-08 15:03:57)

ngoonee · 2011-02-09 00:09:19

falconindy wrote:

Foolish question -- did you enable syslog-ng.service via systemctl after the unit change? I didn't personally make the changes to the unit, and I wasn't a huge fan of said changes... but I suppose I have to deal with them now X.X
edit: ding, 1000 posts.

I don't recall doing that, sorry. I'll try now with disabling it. It certainly starts up anyway. I can't find it in /etc/systemd/system/*, the only reference is to syslog.socket in /lib/systemd/system/sockets.target.wants

czanik · 2011-02-09 07:01:21

FYI: there is an on-going systemd integration at the syslog-ng project in joint work with openSUSE.

The first working patches against syslog-ng 3.2.2 are available in the openSUSE build service at https://build.opensuse.org/package/file … e%3ASystem

The same patches, maybe with some cosmetic changes will go into the next syslog-ng 3.2 and 3.3 releases soon.

Peter Czanik / syslog-ng
http://czanik.blogs.balabit.com/

ngoonee · 2011-02-09 07:51:13

czanik wrote:

FYI: there is an on-going systemd integration at the syslog-ng project in joint work with openSUSE.
The first working patches against syslog-ng 3.2.2 are available in the openSUSE build service at https://build.opensuse.org/package/file … e%3ASystem
The same patches, maybe with some cosmetic changes will go into the next syslog-ng 3.2 and 3.3 releases soon.
Peter Czanik / syslog-ng
http://czanik.blogs.balabit.com/

Thanks czanik, that's good to hear.

falconindy · 2011-02-09 13:53:10

czanik wrote:

FYI: there is an on-going systemd integration at the syslog-ng project in joint work with openSUSE.
The first working patches against syslog-ng 3.2.2 are available in the openSUSE build service at https://build.opensuse.org/package/file … e%3ASystem
The same patches, maybe with some cosmetic changes will go into the next syslog-ng 3.2 and 3.3 releases soon.
Peter Czanik / syslog-ng
http://czanik.blogs.balabit.com/

Wow this is great news! Thanks Peter!

Edit: I've created an AUR package for this, with support for systemd and 2.6.38 (since I've been running rc's lately).

http://aur.archlinux.org/packages.php?ID=46340

I also pushed a minor change to the syslog-ng.service file in systemd-arch-units and tested it on my work machine.

Last edited by falconindy (2011-02-09 14:48:47)

tomegun · 2011-02-09 21:56:45

I'm guilty of changing the syslog-ng.service file, sorry if it broke for someone. It was done to prepare for the socket activation support that will arrive soon in syslog-ng.

There is an integration branch of the systmed support for syslog-ng here: git://git.madhouse-project.org/syslog-ng/syslog-ng-3.2.git, it has some other required fixes as well as the patch from SuSE.

falconindy · 2011-02-10 14:42:46

tomegun wrote:

There is an integration branch of the systmed support for syslog-ng here: git://git.madhouse-project.org/syslog-ng/syslog-ng-3.2.git, it has some other required fixes as well as the patch from SuSE.

The patch I've included with syslog-ng-systemd looks to be a diff of the master and systemd-integration branches on that repo. Thanks for pointing out where it came from though, I'll be keeping an eye on it.

Viper_Scull · 2011-02-10 18:09:21

I'm getting this error with polkitd:

polkitd[2834]: Error loading /var/run/ConsoleKit/database: Error statting file /var/run/ConsoleKit/database: No such file or directory** (polkitd:2834): DEBUG: Added `/var/lib/polkit-1/localauthority/10-vendor.d' as a local authorization store

But the file does exist.

and i linked mtab to /proc/self/mounts but readahead claims there are too many levels of symbolic links:

systemd-readahead-replay[622]: open(/etc/mtab) failed: Too many levels of symbolic links

Last edited by Viper_Scull (2011-02-10 18:22:34)

falconindy · 2011-02-10 21:24:06

@Viper_Scull: Your first error isn't even systemd related, and I have no idea about the latter. I've linked /etc/mtab -> /proc/self/mounts on multiple machines and I can't find that error on any of them.

Arch Linux

#151 2011-01-28 08:07:26

Re: systemd: Yet Another Init Replacement

#152 2011-01-28 11:07:44

Re: systemd: Yet Another Init Replacement

#153 2011-01-28 15:52:08

Re: systemd: Yet Another Init Replacement

#154 2011-01-28 16:13:18

Re: systemd: Yet Another Init Replacement

#155 2011-02-04 16:30:32

Re: systemd: Yet Another Init Replacement

#156 2011-02-06 01:44:16

Re: systemd: Yet Another Init Replacement

#157 2011-02-06 04:57:38

Re: systemd: Yet Another Init Replacement

#158 2011-02-06 05:27:01

Re: systemd: Yet Another Init Replacement

#159 2011-02-06 05:41:44

Re: systemd: Yet Another Init Replacement

#160 2011-02-07 15:24:37

Re: systemd: Yet Another Init Replacement

#161 2011-02-08 01:50:05

Re: systemd: Yet Another Init Replacement

#162 2011-02-08 02:25:31

Re: systemd: Yet Another Init Replacement

#163 2011-02-08 11:14:04

Re: systemd: Yet Another Init Replacement

#164 2011-02-08 13:05:04

Re: systemd: Yet Another Init Replacement

#165 2011-02-08 14:10:47

Re: systemd: Yet Another Init Replacement

#166 2011-02-08 14:27:14

Re: systemd: Yet Another Init Replacement

#167 2011-02-08 15:03:40

Re: systemd: Yet Another Init Replacement

#168 2011-02-09 00:09:19

Re: systemd: Yet Another Init Replacement

#169 2011-02-09 07:01:21

Re: systemd: Yet Another Init Replacement

#170 2011-02-09 07:51:13

Re: systemd: Yet Another Init Replacement

#171 2011-02-09 13:53:10

Re: systemd: Yet Another Init Replacement

#172 2011-02-09 21:56:45

Re: systemd: Yet Another Init Replacement

#173 2011-02-10 14:42:46

Re: systemd: Yet Another Init Replacement

#174 2011-02-10 18:09:21

Re: systemd: Yet Another Init Replacement

#175 2011-02-10 21:24:06

Re: systemd: Yet Another Init Replacement

Board footer