Systemd, tmux and rTorrent

Hello.
I finally found some time to migrate to systemd. Almost everything went smooth, there is only one thing I can't figure out. I want to run rtorrent in dedicated tmux session as user (not root). With initscripts basically it was enough to run
su - kaz -c 'tmux new-session -d -s rtorrent rtorrent' &> /dev/null
in /etc/rc.d/rtorrent and add rtorrent to DAEMONS array.
In systemd I've tried to write my own .service file and run systemctl enable rtorrent.service. That's what I have in /etc/systemd/system/rtorrent.service:
[Unit]
Description=rTorrent for kaz
[Service]
ExecStart=/usr/bin/tmux new-session -d -s rtorrent rtorrent
Type=oneshot
User=kaz
[Install]
WantedBy=multi-user.target
And it even works when I run systemctl start rtorrent.service (I have new session with rtorrent in tmux), but it doesn't after reboot. The output of systemctl status rtorrent.service is the same right after reboot and after manually starting rtorrent.service (except the time and PID of course):
[kaz@Dmitrij system]$ systemctl status rtorrent.service
rtorrent.service - rTorrent for kaz
Loaded: loaded (/etc/systemd/system/rtorrent.service; enabled)
Active: inactive (dead) since Wed, 15 Aug 2012 17:32:38 +0200; 16min ago
Process: 408 ExecStart=/usr/bin/tmux new-session -d -s rtorrent rtorrent (code=exited, status=0/SUCCESS)
CGroup: name=systemd:/system/rtorrent.service
[kaz@Dmitrij system]$
Does tmux depend on anything to run? Some variables maybe?
And it would be great if I could get systemd to restart rtorrent when it exits, but I'm not sure how to do that...
Last edited by kazuldur (2012-08-15 16:06:49)

cngn wrote:
You need Type=oneshot. Type=forking will prevent you from using multiple tmux sessions. Try this: first run 'tmux new -s test -d'. Then start your session 'systemctl start rt@user'. Then run 'tmux ls'.
space@arch ~ :( $ cat /etc/systemd/system/[email protected]
[Unit]
Description=Start tmux in detached session
[Service]
Type=forking
KillMode=none
User=%I
ExecStart=/usr/bin/tmux new-session -s %u -d
ExecStop=/usr/bin/tmux kill-session -t %u
[Install]
WantedBy=multi-user.target
space@arch ~ $ tmux ls
failed to connect to server
space@arch ~ :( $ tmux new -s test -d && tmux ls
test: 1 windows (created Sun May 5 19:36:33 2013) [144x39]
space@arch ~ $ sudo systemctl start tmux@space
space@arch ~ $ tmux ls
test: 1 windows (created Sun May 5 19:36:33 2013) [144x39]
space@arch ~ $
Thanks for that, I did not notice that. However now I get something weird, if I already had a tmux session running, this simply merges the new windows into it (at least that it what is looks like from htop)
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
1 root 20 0 32772 3560 1944 S 0.0 0.0 0:02.77 /sbin/init
29363 hans 20 0 18228 1820 1268 S 0.0 0.0 0:00.38 ├─ tmux new-session -d -s test
30787 hans 20 0 16252 2732 1684 S 0.0 0.0 0:00.01 │ ├─ -bash
30512 hans 20 0 189M 28044 6364 S 0.0 0.2 0:00.35 │ ├─ /usr/bin/irssi
30520 hans 20 0 189M 28044 6364 S 0.0 0.2 0:00.00 │ │ └─ /usr/bin/irssi
30508 hans 20 0 434M 160M 5220 S 0.0 1.3 0:01.76 │ └─ /usr/bin/rtorrent
30521 hans 20 0 434M 160M 5220 S 0.0 1.3 0:00.00 │ ├─ /usr/bin/rtorrent
30511 hans 20 0 434M 160M 5220 S 0.0 1.3 0:00.00 │ └─ /usr/bin/rtorrent
but if I go to the user and do 'tmux list-sessions', its shows 2 sessions:
$ tmux list-sessions
rt: 2 windows (created Sun May 5 19:50:46 2013) [80x23]
test: 1 windows (created Sun May 5 19:19:20 2013) [80x23]
I'll read up a bit more on tmux (i think this might be a tmux related, and not something to do with systemd).

Similar Messages

[solved] systemd-journal and shadow.pacnew updates

After a recent install and update I have come across the same issue described here where the user was recommended to ignore and erase some .pacnew files. My update generated the following:
/etc/dhcpcd.conf.pacnew
/etc/group.pacnew
/etc/passwd.pacnew
/etc/shadow.pacnew
/etc/gshadow.pacnew
The first, dhcpcd, seemed sensible enough and I incorporated the changes. The latter four all share the following characteristics:
1. Removed mentions of systemd-journal-remote and systemd-journal-upload. I'm not sure why so I left those records in place.
2. Changed a few permissions here or there, which i incorporated into /etc/group and /etc/password.
3. Changed the default shell for a few users; these changes I incorporated.
I was unable to open /etc/shadow or /etc/gshadow in write mode so I've left these files. Perhaps that's fine because the thread mentioned above says so. However, there's no explanation of why or where this information was obtained (or ordained!)
Is it fine to leave these two files? Why have syssystemd-journal-remote and systemd-journal-upload been omitted?
Last edited by Deau (2014-08-29 06:54:18)

The steps you took look quite sane to me.
These groups are not in the defaults provided by filesystem (e.g. I don't have them). see the edit
Apparently systemd creates system groups and users on it's own, see 'man systemd-sysusers'. Do you know / can figure out why these groups are created in the first place ? not important in this case, see the edit as well
FYI e.g.: https://bugs.archlinux.org/task/41717
The filesystem package provides those files as defaults (group, passwd, shadow, gshadow amongst otheres). However there are some packages that actually add additional groups they need (like ntp e.g.). The filesystem package cannot know about these. Therefor it's likely to have more groups in your local installation than in the .pacnew files you get.
The same applies for manually created users and groups of course.
If needed see the man pages for explanations of the respective files (e.g. 'man group').
Edit: Ok, I see that after an update I have them as well, so these are apparently new systemd groups and users. I think the rest I said above is still valid, so leaving those in place was the right thing to do.
Last edited by rebootl (2014-08-28 20:46:43)

Tmux and xsession detachment, failed to commit changes to dconf

Hi guys, I just moved over from Linux Mint to Arch Linux, and am trying to set up my desktop environment in a similar fashion.
I'm currently running cinnamon desktop environment.
Following https://wiki.archlinux.org/index.php/tmux , I've installed tmux and am experiencing an issue.
When in gnome-terminal with tmux session started, I tried to run applications like 'nemo' and 'gitg'.
The terminal keeps printing warnings whenever I tried to do re-sizing of the UI elements e.g. split pane, window resizing. Of course, the UI resizing doesn't work too and reverts back to default, causing annoyance.
dconf-WARNING **: failed to commit changes to dconf: Could not connect: Connection refused
Searching the forum, I came across this topic https://bbs.archlinux.org/viewtopic.php?id=165485 which hints on corrupted dconf file. I tried the the fix without success.
After further digging, I found a comment in launchpad bug-tracker https://bugs.launchpad.net/ubuntu/+sour … bug/975889.
Sepero (cowpie2000) wrote:I discovered that this problem was occurring because the terminal (running in screen) was no longer attached to the current Xsession. So the only issue here is that the output message could be more clear.
Using the hint above, I did a test by running the applications in plain gnome-terminal without tmux, the above warning does not appear, and all UI behaviours are as per normal.
If the xsession detachment issue is indeed the case, then I probably must have missed a config settings somewhere for tmux, gnome-terminal, bash, or other related settings.
I'm all ears for some direction where I can look into to address this issue.
Thank you.
Edit: After posting this thread, a package update and system reboot caused the issue to disappear. I can no longer reproduce the issue at the moment.
Last edited by VKen (2014-05-22 04:02:54)

http://btsc.webapps.blackberry.com/btsc/viewdocument.do;jsessionid=6C2558D8948FCC7938F2B419C24ACBC2?...
The above article may or may not help.

Systemd: Suspend and Hibernate not working

Hi,
When I try to hibernate my Notebook using systemd with 'systemctl hibernate', it sometimes (from time to time it even works) fails with the error message "a dependency job for hibernate.target failed". In the journal I see the following:
The system clock has been changed to REALTIME microseconds after January 1st, 1970.
Jun 04 23:52:57 localhost systemd[1]: systemd-hibernate.service: main process exited, code=exited, status=1/FAILURE
Jun 04 23:52:57 localhost systemd[1]: Failed to start Hibernate.
-- Subject: Unit systemd-hibernate.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/li … temd-devel
-- Unit systemd-hibernate.service has failed.
-- The result is failed.
Jun 04 23:52:57 localhost systemd[1]: Dependency failed for Hibernate.
-- Subject: Unit hibernate.target has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/li … temd-devel
-- Unit hibernate.target has failed.
-- The result is dependency.
Jun 04 23:52:57 localhost systemd[1]: Service sleep.target is not needed anymore. Stopping.
Jun 04 23:52:57 localhost systemd[1]: Unit systemd-hibernate.service entered failed state.
Jun 04 23:52:57 localhost systemd[1]: Stopping Sleep.
-- Subject: Unit sleep.target has begun shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/li … temd-devel
-- Unit sleep.target has begun shutting down.
Jun 04 23:52:57 localhost systemd[1]: Stopped target Sleep.
-- Subject: Unit sleep.target has finished shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/li … temd-devel
-- Unit sleep.target has finished shutting down.
:x
Any ideas? Furthermore, during hibernate (when it works) my screen first gets black, the system comes back and only then it really hibernates.
Others suggest switching to linux-lts. Does that really make sense? Isn't this a systemd issue?
suspend sometimes fails to work either (screen gets blank, but system weaks up after a few seconds again):
Jun 05 06:59:14 localhost systemd[1]: Stopping Sleep.
-- Subject: Unit sleep.target has begun shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/li … temd-devel
-- Unit sleep.target has begun shutting down.
Jun 05 06:59:14 localhost systemd[1]: Stopped target Sleep.
-- Subject: Unit sleep.target has finished shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/li … temd-devel
-- Unit sleep.target has finished shutting down.
Jun 05 06:59:14 localhost systemd[1]: Reached target Suspend.
-- Subject: Unit suspend.target has finished start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/li … temd-devel
-- Unit suspend.target has finished starting up.
-- The start-up result is done.
Thanks,
Michael

Thanks, but I do not call systemd-sleep manually, I just do the ordinary "systemctl hibernate".
Unfortunately, the error "A dependency job for hibernate.target failed. See 'journalctl -xn' for details" just happened again. Alas, I'm not able to debug it according to the manual (https://wiki.archlinux.org/index.php/sy … emd_errors). When I try to get the log messages for the PID that causes hibernate.service to fail, I don't see anything suspicious in the logs:
$ sudo systemctl status systemd-hibernate.service
systemd-hibernate.service - Hibernate
Loaded: loaded (/usr/lib/systemd/system/systemd-hibernate.service; static)
Active: failed (Result: exit-code) since Fri 2014-06-13 14:32:52 CEST; 12min ago
Docs: man:systemd-suspend.service(8)
Process: 26712 ExecStart=/usr/lib/systemd/systemd-sleep hibernate (code=exited, status=1/FAILURE)
Main PID: 26712 (code=exited, status=1/FAILURE)
Jun 13 14:32:37 localhost systemd[1]: Starting Hibernate...
Jun 13 14:32:37 localhost systemd-sleep[26712]: Suspending system...
Jun 13 14:32:52 localhost systemd[1]: systemd-hibernate.service: main process exited, code=exited, status=1/FAILURE
Jun 13 14:32:52 localhost systemd[1]: Failed to start Hibernate.
Jun 13 14:32:52 localhost systemd[1]: Unit systemd-hibernate.service entered failed state.
$ sudo journalctl -b _PID=XXXX
-- Logs begin at Thu 2013-09-26 16:12:25 CEST, end at Fri 2014-06-13 14:43:40 CEST. --
Jun 13 14:32:37 localhost systemd-sleep[26712]: Suspending system...
Any ideas?

How does systemd, wpa_supplicant, and dhcpcd work together? rtl8188su

I'm running arch with alarm (done a pacman -Syu to get latest everything) on an original Raspberry Pi model B.
I'm using a Belkin USB adapter which is really a Realtek rtl8188su chip, which is recognized with the r8712u module. I want to do it all from the command line (not running a GUI, as this Pi won't be having a display attached.)
The system recognizes the built-in Ethernet, and dhcpcd assigns it an IP address, so I can SSH into it and try to bring up the wlan0 interface.
I'm an old-school Linux/UNIX hacker, but I haven't had a lot of experience with systemd, nor with wpa_supplicant or even much of udev, so I'm a bit lost in trying to make this work.
I made sure wpa_supplicant and wpa_cli were installed. Then I edited /etc/wpa_supplicant/wpa_supplicant.conf to add my ssid/passphrase, and saved it as /etc/wpa_supplicant/wpa_supplicant.wlan0.conf. I also did "systemctl enable wpa_supplicant," and I've rebooted.
The status of the system is that it does not enable the wlan0 interface. Further, the wpa_cli tool does not work. If I run just "wpa_cli" or with a command like "wpa_cli list" then I get the error:
could not connect to wpa_supplicant - wpa_ctrl_open: No such file or directory
This is weird, because wpa_supplicant is running in dbus listen mode:
[root@alarmpi ~]# ps alx | grep [w]pa
0 0 94 1 20 0 5636 1416 poll_s Ss ? 0:00 /usr/sbin//wpa_supplicant -u
Each time I boot, I get this message in /dev/log/messages.log:
Nov 10 01:40:06 alarmpi kernel: [ 648.082619] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Now, if I insted does "systemctp stop wpa_supplicant" and start it manually, it does bring up the interface:
[root@alarmpi ~]# wpa_supplicant -i wlan0 -D wext -c /etc/wpa_supplicant/wpa_supplicant.wlan0.conf
wlan0: Trying to associate with a0:21:b7:63:a1:98 (SSID='jwatte' freq=2462 MHz)
wlan0: Associated with a0:21:b7:63:a1:98
wlan0: WPA: Key negotiation completed with a0:21:b7:63:a1:98 [PTK=CCMP GTK=CCMP]
wlan0: CTRL-EVENT-CONNECTED - Connection to a0:21:b7:63:a1:98 completed (auth) [id=0 id_str=]
[root@alarmpi ~]# ifconfig wlan0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::a86:3bff:feb4:c21a prefixlen 64 scopeid 0x20<link>
ether 08:86:3b:b4:c2:1a txqueuelen 1000 (Ethernet)
RX packets 30 bytes 3813 (3.7 KiB)
RX errors 0 dropped 1 overruns 0 frame 0
TX packets 5 bytes 610 (610.0 B)
TX errors 0 dropped 1 overruns 0 carrier 0 collisions 0
[root@alarmpi ~]#
However, dhcpcd is not auto-launched to provide an IP address to the interface.
So, how is this supposed to work? How am I supposed to configure the system so that all the pieces click together? It should start wpa_supplicant with the right config data, and/or configure it over dbus correctly, and it should make sure dhcpcd is then invoked to obtain an IP address. I have *no idea* how to actually configure this to do the right thing, because all the tutorials and documentation I can find on the web is either very abstract ("services live in /usr/lib/systemd/...") or just claim that things "will magically work" if I have the correct configuration.
Help! Don't know what to do next!

Your manual wpa_supplicant invocation result looks good, so the major hurdle you have taken already.
For wireless you need a management method that acts as interface to wpa_supplicant and dhcp and watches the connection. Before you browse off to archlinuxarm, also read the non-abstract introduction here: https://wiki.archlinux.org/index.php/Wi … management

KDE, Systemd, NM and double suspsend

So, first, don't get me wrong, it's not the same problem that happened when KDE doesn't support systemd inhibit.
Since NM 0.9.6.4, nm begin to add a new inhibit, seems to be used to track suspend status. But this seems cause double suspend for me again.
When I close the lid and suspend with KDE, and when I want to resume, I have to resume it for second time since it just suspends immediately again.
This is what I get.
$ systemd-inhibit --list
WHAT WHO WHY MODE UID PID
handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch PowerDevil KDE handles p...ents block 1000 1068
sleep root inhibited delay 0 359
Second one comes from NM.
And if I downgrade NM to 0.9.6.0, problem will be solved, so I'm partly sure it's is related to this NM "new feature".
I even drop a report on systemd but so far no reply: https://bugs.freedesktop.org/show_bug.cgi?id=58220
Does anyone also have this problem know how to resolve it? Thanks! Not a big deal, just annoying...

csslayer wrote:Does anyone also have this problem know how to resolve it? Thanks! Not a big deal, just annoying...
Yes, I have the same issue, I'm using KDE as well. Unfortunately I don't know how to solve it.
[ericd@vaiopro13 ~]$ systemd-inhibit --list
WHAT WHO WHY MODE UID PID
handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch PowerDevil KDE handles p...ents block 1000 512
sleep root inhibited delay 0 310
root 310 0.0 0.1 247480 9060 ? Ssl 19:14 0:02 /usr/sbin/NetworkManager --no-daemon

Systemd-tmpfiles and gvfs - permission denied

systemd-tmpfiles[2346]: stat(/run/user/1000/gvfs) failed: Permission denied
Can anyone tell me why this is in my journalctl ? Sometimes many times, depending on the application I use,
other times, once or twice in a 5 hour uptime.

same here with systemd. From log file:
localhost systemd-tmpfiles[12898]: stat(/run/user/1000/gvfs) failed: Permission denied
[gabx@magnolia:1000]$ ls -al
dr-x------ 2 gabx users 0 Aug 31 21:32 gvfs
[gabx@magnolia:1000]$ chmod -R u+w gvfs
[gabx@magnolia:1000]$ ls -al
dr-x------ 2 gabx users 0 Aug 31 21:32 gvfs
As you can see, can't even change permission for user gabx to write the directory.
EDIT:
[gabx@magnolia:~]$ systemctl status systemd-tmpfiles-setup.service
systemd-tmpfiles-setup.service - Recreate Volatile Files and Directories
Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-setup.service; enabled)
Active: active (exited) since Fri, 31 Aug 2012 21:32:00 +0200; 46min ago
Docs: man:tmpfiles.d(5)
Process: 353 ExecStart=/usr/bin/systemd-tmpfiles --create --remove (code=exited, status=0/SUCCESS)
CGroup: name=systemd:/system/systemd-tmpfiles-setup.service
[gabx@magnolia:~]$ sudo systemctl status systemd-tmpfiles-setup.service
systemd-tmpfiles-setup.service - Recreate Volatile Files and Directories
Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-setup.service; enabled)
Active: active (exited) since Fri, 31 Aug 2012 21:32:00 +0200; 47min ago
Docs: man:tmpfiles.d(5)
Process: 353 ExecStart=/usr/bin/systemd-tmpfiles --create --remove (code=exited, status=0/SUCCESS)
CGroup: name=systemd:/system/systemd-tmpfiles-setup.service
Following the above status, it seems everything is OK, so I am not sure this permission denied is really an issue.
Last edited by gabx (2012-08-31 23:31:01)

X-systemd.automount and sshfs

I've been using sshfs to access files on my pi for serveral months now. Today i tried to enable automatic mounting with x-systemd.automount, but although a manual mount is still possible, the automatic mount fails constantly with a "no such device" error since i added the additional option in /etc/fstab. Journalctl -f on the pi reveals that the "Connection is closed [preauth]", so I would guess that something is wrong with my client authenticating. But I don't understand how is this possible because I can in fact mount the partition manually. Even if I use the exact command used by systemd (found via ps -fe) with root it prompts me for the password of my key and then it mounts correctly. Shouldn't automount then prompt for my password, when my X starts? Any ideas?
line in /etc/fstab:
herrzinter-pi.local:/media/mediacrypt /home/herrzinter/Multimedia fuse.sshfs users,noauto,_netdev,reconnect,x-systemd.automount 0 0
Last edited by MrTea (2013-07-01 15:34:13)

WonderWoofy is right, until now I always used the automatically generated nautilus entry to mount the remote folder. In this case mount command is executed as <user> and so I don't need to put the additional information in the /etc/fstab. btw i didn't exactly look this up, but I've used this setup for quiet some time now, and I guess, that I forgot the herrzinter@ part once and noted that it worked anyway
I now added this and the "IdentityFile=/..." option pointing to a dummy ssh key without passphrase and it then it's working, but I am not to happy with this, as an empty passphare key is not really nice, and also nautilus is showing me duplicated entries... but in genreal I have to look at the setup again I am not sure anymore if the x-systemd.automount option is really such a good idea in my case, as the network setup of my laptop is changing quite often... perhaps a bash script at login, or a custom systemd unit is better suited for my purpose
Thank you all anyway

[SOLVED] systemd, autofs and lxdm

OK, after recently migrating rc.conf to the more 'systemd' structure, but still using init I figured I'd give systemd another shot, and herein lies my problem.
According to the wiki there should already be units available for various DMs, though i only have xdm available. I've copied and modified the copied version for lxdm (well, not strictly correctly, I've modified it to start xfce the same way that my "old" style does, with ck-launch) but I just get dumped to a root desktop (which I can't log out of). What I want is the lxdm login. I'm pretty sure there's a bunch of stuff I've forgotten since I set this up, so how do I get systemd to launch lxdm to a login screen.
Second. I'm getting autofs errors at boot, and automounting isn't available.
Google has helped me not one jot (either lousy googling or lousy forum thread titles, not sure which) and I need to fix this too.
Not looking for a verbatim answer. Rather looking for links where I can get the why's and wherefore's. The Arch systemd wiki doesn't cover this (it assumed units present which are not).
I've installed the arch units already. Any pointers would be appreciated.
Last edited by Roken (2012-07-28 22:25:06)

lxdm package from Community contains usr/lib/systemd/system/lxdm.service
please check with
pacman -Ql lxdm
But if you can't
systemctl enable lxdm.service
you can try manually symlink it
ln -s '/usr/lib/systemd/system/lxdm.service' '/etc/systemd/system/display-manager.service'
btw. in AUR pkgbuilds there are no lxdm.service at the moment, so you neet to copy it from community source files (best way)
Last edited by nbvcxz (2012-07-26 11:28:11)

[SOLVED] systemd reboot and poweroff as user

I decided to try systemd and all my services are working but I cannot reboot or poweroff as user.
$ systemctl poweroff
Failed to issue method call: Access denied
Failed to issue method call: Access denied
I also get that duplicate message for systemctl reboot.
According to the systemd wiki article, I should be able to reboot and poweroff as user and even if not, I should be given the opportunity to provide the root password, but I was not. Both commands work as expected if I su to root. Any suggestions? Thanks.
Last edited by kekules_dream (2012-08-13 10:14:50)

@Smasher816 - the op is right that he/she should be able to reboot, shutdown without superuser access with systemd. I just began using systemd and mine seems to work fine. You aren't logged in as root or another user in another terminal or tty are you? I know that you should STILL be given the option to enter the root password and shutdown, but that is the best I can think of at the moment

Systemd, pacman and kernel modules

Just a thought, once Arch has transferred to systemd, would it not be pretty easy to get pacman to install a conf file under /etc/modules-conf/ automatically, and remove it on uninstall?

xduugu wrote:
12eason wrote:Just a thought, once Arch has transferred to systemd, would it not be pretty easy to get pacman to install a conf file under /etc/modules-conf/ automatically, and remove it on uninstall?
That's already the case for several modules, e.g. tp_smapi, and is independent from systemd. Also see Tom's mail.
Okay, so why the inconsistency?
Tom's mail
The reasoning being that an admin is almost certainly not going to
want to install a package and then not follow the post-install
instructions. Conversely, on un-install (s)he is likely to want to
revert these changes.
Totally agree.
Last edited by 12eason (2012-08-29 22:20:51)

Systemd Udev and USB Problems

Hi everybody, I have an issue with my usbs they are poweroff/suspend and i cant change autosuspend rules.
Im on
OS: Arch Linux x86_64 / Gnome3
Running SYSTEMD (without RC.conf)
I dont have /etc/modprobe.d/options (I try this and not work)
Laptop-mode is not running
laptop-mode.service - Laptop Mode Tools
   Loaded: loaded (/usr/lib/systemd/system/laptop-mode.service; disabled)
   Active: inactive (dead)
   CGroup: name=systemd:/system/laptop-mode.service
So, how i fix this??
The only way that my usb work its booting with a usb-stick plugged, for udev/systemd recognize them.
Thanks folks

lea_b wrote:autosuspend rules
Have you seen thread.

[SOLVED] Run script on systemd shutdown and reboot

Hello!
I am trying to log uptime on shutdown and reboot with no success.
I create the file /usr/lib/systemd/system/uptime.service:
[Unit]
Description=/etc/rc.local.shutdown Compatibility
ConditionFileIsExecutable=/etc/rc.local.shutdown
DefaultDependencies=no
After=rc-local.service basic.target
Before=shutdown.target
[Service]
Type=oneshot
ExecStart=/etc/rc.local.shutdown
StandardInput=tty
RemainAfterExit=yes
[Install]
WantedBy=shutdown.target
/etc/rc.local.shutdown:
[jribeiro@arkosta ~]$ ls -l /etc/rc.local.shutdown
-rwxr-xr-x 1 root root 107 Out 24 12:42 /etc/rc.local.shutdown
[jribeiro@arkosta ~]$ cat /etc/rc.local.shutdown
echo "$(date) - $(/usr/bin/uptime | sed 's/.*up $[^,]*$, .*/\1/')" >> /home/jribeiro/registo_de_uptime
Any ideas?
Last edited by joseribeiro (2014-10-25 19:57:59)

I altered the uptime unit file:
[jribeiro@arkosta ~]$ cat /usr/lib/systemd/system/uptime.service
[Unit]
Description=/etc/rc.local.shutdown Compatibility
Before=shutdown.target
[Service]
ExecStart=/bin/true
ExecStop=/etc/rc.local.shutdown
RemainAfterExit=yes
[Install]
WantedBy=shutdown.target
Then I started the uptime service manually:
[jribeiro@arkosta ~]$ sudo systemctl start uptime
I checked the 'registo_de_uptime' file:
[jribeiro@arkosta ~]$ cat /home/jribeiro/registo_de_uptime
Sáb Out 25 19:43:31 WEST 2014 - 2 min
After that I rebooted my system.
I checked the 'registo_de_uptime' file, again:
[jribeiro@arkosta ~]$ cat /home/jribeiro/registo_de_uptime
Sáb Out 25 19:43:31 WEST 2014 - 2 min
Sáb Out 25 19:44:27 WEST 2014 - 3 min
Everything seems to be alright. I wanted to make the ultimate test.
With that in mind I rebooted the system.
I checked the 'registo_de_uptime' file, once more:
[jribeiro@arkosta ~]$ cat /home/jribeiro/registo_de_uptime
Sáb Out 25 19:43:31 WEST 2014 - 2 min
Sáb Out 25 19:44:27 WEST 2014 - 3 min
No success...
It works when I start the service manually and in the right next reboot, after that it won't work.
Here is the journal's ouput:
[jribeiro@arkosta ~]$ sudo journalctl -b -0 -u uptime
-- Logs begin at Sex 2014-10-24 22:02:03 WEST, end at Sáb 2014-10-25 20:05:29 WEST. --
By the way:
[jribeiro@arkosta ~]$ sudo systemctl status uptime
● uptime.service - /etc/rc.local.shutdown Compatibility
Loaded: loaded (/usr/lib/systemd/system/uptime.service; enabled)
Active: inactive (dead)
Last edited by joseribeiro (2014-10-25 19:07:32)

Systemd --user and network-online.target

I am trying to set up a user timer unit to whose service should be triggered only after the network has become online. The problem is that the network.target and network-online.target are system targets and not available for the --user daemon. Is there anyway to achieve this?

I wonder if you are on the right track using --user? The man page says this option is "of little use except for debugging".

Systemd service and root script

I have simple "regroup.service" for systemd, it excue on start "script.sh". Systemd excue "regroup.service" on start but command in script requires root permission.
-rwxr--r-- 1 root root 316 05-31 21:24 /usr/lib/systemd/scripts/script.sh
Which way is the best for excue script via systemd?
Last edited by sobota (2013-05-31 20:19:11)

Script do:
#!/bin/sh
exist=false
start(){
fil=$(ls /dev/nvidia* | wc -l)
if [ $fil != "0" ]
then
exist=true
chgrp video /dev/nvidia*
fi
stop(){
if [ $exist ]
then
chgrp root /dev/nvidia*
fi
case $1 in
start|stop) "$1" ;;
*) echo "You should pass correct options like start or stop" ;;
esac
When I call service "#systemctl start regroup" group is changed.
Last edited by sobota (2013-05-31 22:13:37)

Systemd, tmux and rTorrent

Similar Messages

Maybe you are looking for