You are not logged in.
Just wanted to say that I am now running systemd on my arch installation, and it is fantastic.
Well-documented.
Organized (could be better; would rather all the *.{service,target,socket,etc} be organized into folders)
Integrates with sysV very well
systemd makes init and upstart look antiquated, in my opinion. Finally, we have a dynamic daemon and system manager.
Offline
Hi.
I'm trying systemd for the first time, and I have a little issue:
I have a bluetooth usb dongle, and when I plug it, the bluetooth icon does not appear, although everything works fine: I can pair, send and receive files through the control center etc etc etc...
Booting without systemd this issue does not happens.
I'm using the gnome 3.2 beta from [gnome-unstable], but since wuthout systemd I don't have the problem, I don't think is related...
Somebody experiencing the same, or it's just me?
Offline
Hi.
I'm trying systemd for the first time, and I have a little issue:
I have a bluetooth usb dongle, and when I plug it, the bluetooth icon does not appear, although everything works fine: I can pair, send and receive files through the control center etc etc etc...
Booting without systemd this issue does not happens.I'm using the gnome 3.2 beta from [gnome-unstable], but since wuthout systemd I don't have the problem, I don't think is related...
Somebody experiencing the same, or it's just me?
Is bluetooth.service enabled?
Offline
jorchube wrote:Hi.
I'm trying systemd for the first time, and I have a little issue:
I have a bluetooth usb dongle, and when I plug it, the bluetooth icon does not appear, although everything works fine: I can pair, send and receive files through the control center etc etc etc...
Booting without systemd this issue does not happens.I'm using the gnome 3.2 beta from [gnome-unstable], but since wuthout systemd I don't have the problem, I don't think is related...
Somebody experiencing the same, or it's just me?
Is bluetooth.service enabled?
Yes it is. Enabled, loaded, active and running
As I said, the icon is not shown but I can send, receive, pair... etc with other devices.
Offline
Using kde, programs like amarok or digikam flood my logs with messages like
dbus-daemon[1051]: ** (udisks-daemon:1426): WARNING **: Property get or set
does not have an interface string as first arg
this bug was already reported to bugs.kde.org https://bugs.kde.org/show_bug.cgi?id=281812 and it turned out, that only systemd users are affected.
Is this is a bug in kde or in systemd?
crabman
Offline
Using kde, programs like amarok or digikam flood my logs with messages like
dbus-daemon[1051]: ** (udisks-daemon:1426): WARNING **: Property get or set does not have an interface string as first arg
this bug was already reported to bugs.kde.org https://bugs.kde.org/show_bug.cgi?id=281812 and it turned out, that only systemd users are affected.
Is this is a bug in kde or in systemd?
crabman
I'd say this is a KDE (or udisks) bug. The difference is that non-systemd systems will ignore the warnings, whereas systemd puts whatever udisks spits out in the system logs.
-t
Offline
- When I want to modify a (normal) service unit, I copy it to /etc/systemd/system/multi-user.target.wants/ instead of just symlinking, and change the contents. Why can't I do the same with socket units by copying them to /etc/systemd/system/sockets.target.wants/? If I do that, systemd continues to use the version under /lib/systemd/system/ instead of my modified file (even after reboot). I have to actually rename the socket unit (and the associated service unit) for the contents to be respected.
I figured out what causes this strange behavior. Rather than placing my modified (and brand new) units in /etc/systemd/system/, and then linking them into multi-user.target.wants (or another appropriate target), I was creating those unit files directly under the *.target.wants directories. This seems to set up an unpredictable situation, such that which version of the unit systemd loads depends on why it was loaded: if it was only enabled because that target wanted it, my version was used, but if some earlier dependency needed it first, the original was loaded, and mine ignored.
The solution, of course, is not to do that. systemd, as with most software, works much better when it's used properly.
Offline
Since gnome 3.2 i not get a fallback mode when i start with systemd, now my question: How can i start lighttpd from booting?
Offline
I don't use it, but I don't see how systemd would prevent you from having a fallback mode for gnome 3.2. Maybe they removed it?
As for lighthttpd, you'll need to create a .service file for it.
I'm rather lazy, so I just whipped up this one:
[Unit]
Description=Lighttpd web server
[Service]
Type=forking
ExecStart=/etc/rc.d/lighttpd start
ExecStop=/etc/rc.d/lighttpd stop
ExecReload=/etc/rc.d/lighttpd reload
Restart=always
[Install]
WantedBy=multi-user.target
It seems to do the trick. Just save it to /etc/systemd/system, and then "systemctl enable" it.
Systemd seems to be severely lacking in web-related service files, I must say. Unfortunately, I don't know who should be held responsible for that. The systemd devs should be focusing on developing systemd, but the mysql/httpd/lightttpd devs should be focusing on their respective projects too. Maybe systemd isn't big enough for these groups to consider making systemd service/socket/etc files?
Last edited by WorMzy (2011-10-01 23:48:03)
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
I don't use it, but I don't see how systemd would prevent you from having a fallback mode for gnome 3.2. Maybe they removed it?
If you don't have proper access to the DRI components of the video card because your session isn't properly authenticated, then you get a fallback session. It was a known bug in GDM -- I don't know if the fix was ever merged.
Systemd seems to be severely lacking in web-related service files, I must say. Unfortunately, I don't know who should be held responsible for that. The systemd devs should be focusing on developing systemd, but the mysql/httpd/lightttpd devs should be focusing on their respective projects too. Maybe systemd isn't big enough for these groups to consider making systemd service/socket/etc files?
Because lighty in particular is effing insane and refuses to run nicely without the supervisor (lighttpd-angel) process. You either run with the angel and get impossible to control behavior on restart (because the PID changes while systemd tracks the angel), or you run without the supervisor and lose the ability to do graceful restarts. Things like this just seem to be the way things go with all the popular httpd's.
https://github.com/falconindy/systemd-a … ts/pull/15
https://github.com/falconindy/systemd-a … ts/pull/86
Last edited by falconindy (2011-10-02 00:03:00)
Offline
thx use Fedora the same trick with the old init system?
Offline
Here is one I've been working on all weekend...
I have been using systemd for a couple months. Worked fine, including my hackish attempt at writing a service for fail2ban. Last week, I rebooted for the first time in a while. Its kind of hard to tell what happened, but it appears that / was mounted read only, and home did not get mounted at all. Of course, looking at the logs is hopeless as /var is RO.
mount says things are r/w, but I think that is explained by the mount command saying that mount cannot be written (or something to that effect, I am not in front of my machine)
Fortunately, I have a grub entry that still boots with the default initscipts, which work perfectly; except they are so.... slow....
The systemd problem is repeatable and occurs every time, even after starting successfully with the old initscripts
I am wandering in the dark here, Google has not been my friend on this one
Can anyone point me in the right direction? Thanks.
Edit, yes... I did remove my fail2ban hack -- just to make sure I wasn't stepping on myself
Last edited by ewaller (2011-10-03 18:58:48)
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
I also had this behavior a few months ago and nobody here could help me. So I switched back to normal init. Hope someone can help you. Also reinstalling didn't help for me.
Best regards!
Offline
Here is one I've been working on all weekend...
I have been using systemd for a couple months. Worked fine, including my hackish attempt at writing a service for fail2ban. Last week, I rebooted for the first time in a while. Its kind of hard to tell what happened, but it appears that / was mounted read only, and home did not get mounted at all. Of course, looking at the logs is hopeless as /var is RO.
mount says things are r/w, but I think that is explained by the mount command saying that mount cannot be written (or something to that effect, I am not in front of my machine)
Fortunately, I have a grub entry that still boots with the default initscipts, which work perfectly; except they are so.... slow....The systemd problem is repeatable and occurs every time, even after starting successfully with the old initscripts
I am wandering in the dark here, Google has not been my friend on this one
Can anyone point me in the right direction? Thanks.Edit, yes... I did remove my fail2ban hack -- just to make sure I wasn't stepping on myself
Sounds like you don't have /etc/mtab as a symlink to /proc/self/mounts.
Offline
Thanks falconindy,
That makes sense. I'll check that when I get home this evening.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
Sounds like you don't have /etc/mtab as a symlink to /proc/self/mounts.
This week has been insane! I finally worked my way back to this, and you were correct; but that was not the root cause of the issue; It did solve the problem with mount spewing nonsense. I still had things mount as RO and still had no home. I could mount home by hand and see all my precious files -- I just wasn't allowed to touch them
I am afraid I needed a stable system more than I wanted to understand this so I removed and reinstalled systemd and the problem vanished (or maybe is lurking stealth mode in the shadows waiting to pounce). OTOH, maybe I broke something in the original install.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
I am afraid I needed a stable system more than I wanted to understand this so I removed and reinstalled systemd and the problem vanished (or maybe is lurking stealth mode in the shadows waiting to pounce). OTOH, maybe I broke something in the original install.
Been there, sometimes stability is more important at the present moment. I still intend to try systemd again though (especially now that the rt-patch has finally graduated to the latest kernel patch-sets).
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
Just installed systemd and am having a couple problems.
First, systemd does not allow me to log in. At the prompt, I type in my user name, then I type in my password. After that, there's nothing. Nothing happens. When I try logging in as root, I'll type in the user name and password, and then it will tell me when my last login was at least, but it won't actually give me access to the shell.
Second, systemd does not set my clock correctly for some reason. I tried to read the wiki but wasn't sure if it applied.
All of these issues disappear when I start the computer up without systemd.
Offline
I have a problem using laptop mode together with systemd. After laptop-mode-tools service restart I get these messages in the syslog:
Oct 19 15:30:49 localhost laptop_mode[32747]: /usr/sbin/laptop_mode: line 197: /dev/fd/1: Nie ma takiego urządzenia ani adresu
Oct 19 15:30:49 localhost laptop-mode: enabled,
Oct 19 15:30:49 localhost laptop_mode[32747]: /usr/sbin/laptop_mode: line 197: /dev/fd/1: Nie ma takiego urządzenia ani adresu
Oct 19 15:30:49 localhost laptop-mode: not active [unchanged]
Oct 19 15:30:49 localhost laptop_mode[32747]: /usr/sbin/laptop_mode: line 197: /dev/fd/1: Nie ma takiego urządzenia ani adresu
"Nie ma takiego urządzenia ani adresu" means something like "No such device or address".
When starting laptop-mode-tools using the /etc/rc.d/laptop-mode script, no errors appear and laptop-mode starts properly.
EDIT:
Updating laptop-mode-tools to latest version didn't fix the problem. Currently installed versions:
# pacman -Q systemd laptop-mode-tools
systemd 37-1
laptop-mode-tools 1.60-1
Last edited by MAC!EK (2011-10-20 12:42:27)
Offline
Hi, I'm curious about the changes in fstab in the latest updates. These lines were made redundant with the updated initscripts:
devpts /dev/pts devpts defaults 0 0
shm /dev/shm tmpfs nodev,nosuid 0 0
Do these locations get mounted automatically in systemd too, and can thus be removed from my fstab?
Offline
Dunno about the git version, but in the current repo version, these are mounted:
wormzy@sakura[pts/0]:~$ ls /lib/systemd/system/*/* | grep "\.mount$"
/lib/systemd/system/local-fs.target.wants/media.mount
/lib/systemd/system/local-fs.target.wants/var-lock.mount
/lib/systemd/system/local-fs.target.wants/var-run.mount
/lib/systemd/system/sysinit.target.wants/dev-hugepages.mount
/lib/systemd/system/sysinit.target.wants/dev-mqueue.mount
/lib/systemd/system/sysinit.target.wants/sys-fs-fuse-connections.mount
/lib/systemd/system/sysinit.target.wants/sys-kernel-config.mount
/lib/systemd/system/sysinit.target.wants/sys-kernel-debug.mount
/lib/systemd/system/sysinit.target.wants/sys-kernel-security.mount
So unless you have custom mount scripts, I would guess not.
Last edited by WorMzy (2011-10-22 22:23:11)
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
No, they can be removed. There's a large table of guaranteed mounts in mount-setup.c:
static const MountPoint mount_table[] = {
{ "proc", "/proc", "proc", NULL, MS_NOSUID|MS_NOEXEC|MS_NODEV, true },
{ "sysfs", "/sys", "sysfs", NULL, MS_NOSUID|MS_NOEXEC|MS_NODEV, true },
{ "devtmpfs", "/dev", "devtmpfs", "mode=755", MS_NOSUID, true },
{ "tmpfs", "/dev/shm", "tmpfs", "mode=1777", MS_NOSUID|MS_NODEV, true },
{ "devpts", "/dev/pts", "devpts", "mode=620,gid=" STRINGIFY(TTY_GID), MS_NOSUID|MS_NOEXEC, false },
{ "tmpfs", "/run", "tmpfs", "mode=755", MS_NOSUID|MS_NODEV, true },
{ "tmpfs", "/sys/fs/cgroup", "tmpfs", "mode=755", MS_NOSUID|MS_NOEXEC|MS_NODEV, false },
{ "cgroup", "/sys/fs/cgroup/systemd", "cgroup", "none,name=systemd", MS_NOSUID|MS_NOEXEC|MS_NODEV, false },
};
Offline
Need help setting up systemd. I have sshd and dhcdbd fail. I assume it is because it is trying to start those services before network has finished. Can someone help me with proper setup for this?
Edit 1: Checked some examples on gentoo wiki. Tried to start sshd and minidlna service after network.target, didn't seem to work tho. Didn't get around to dhcdbd.
Edit 2: sshd.service works at boot now by setting a static ip instead of relying on dhcp. Still unsure about dhcdbd but I think I read a fix for that about 7 pages back in this thread.
Last edited by nemesis2all (2011-10-23 20:40:20)
Offline
No, they can be removed. There's a large table of guaranteed mounts in mount-setup.c:
static const MountPoint mount_table[] = { { "proc", "/proc", "proc", NULL, MS_NOSUID|MS_NOEXEC|MS_NODEV, true }, { "sysfs", "/sys", "sysfs", NULL, MS_NOSUID|MS_NOEXEC|MS_NODEV, true }, { "devtmpfs", "/dev", "devtmpfs", "mode=755", MS_NOSUID, true }, { "tmpfs", "/dev/shm", "tmpfs", "mode=1777", MS_NOSUID|MS_NODEV, true }, { "devpts", "/dev/pts", "devpts", "mode=620,gid=" STRINGIFY(TTY_GID), MS_NOSUID|MS_NOEXEC, false }, { "tmpfs", "/run", "tmpfs", "mode=755", MS_NOSUID|MS_NODEV, true }, { "tmpfs", "/sys/fs/cgroup", "tmpfs", "mode=755", MS_NOSUID|MS_NOEXEC|MS_NODEV, false }, { "cgroup", "/sys/fs/cgroup/systemd", "cgroup", "none,name=systemd", MS_NOSUID|MS_NOEXEC|MS_NODEV, false }, };
Ah, excellent. Thank you.
Offline