Re: [arch-general] unable to boot up
On Sun, Nov 04, 2012 at 01:20:03AM -0300, Martín Cigorraga wrote: > On Fri, Nov 2, 2012 at 7:24 AM, Tom Rand wrote: > > > the initial issue was caused by systemd trying to load cdemu kernel module > > which was removed by vmware! > > once i removed the .conf file from /etc/modules.d/ normality crept back BUT > > my nic was not being initialised as the r8169 was refusing to load. > > I then assumed most of my modules were corrupted some how hence why they > > were failing to load (even modprobe was failing), a possibility that me > > running vmware-modconfig [...] as stated in my initial post caused this > > but i have no way to disprove or prove this but i resolved this by > > re-installing the kernel & headers. > > > > thanks for time taken in reading this. > > > > > > On Thu, Nov 01, 2012 at 03:31:13PM +0200, Thomas Rand wrote: > > > Hey Archers, > > > my issue begins with me trying to patch vmware for 3.6.3-1-arch > > > I tried using vmware & this told me the modules were not present for > > > 3.6.3 so I went to grab latest from AUR (vmware-patch), the comments > > > on there suggested that the ones for 3.5.x still worked but needed to > > > be rebuilt. > > > > > > so I read these instructions: > > > https://wiki.archlinux.org/index.php/VM … stallation > > > > > > I noticed that in the finishing up section it gave a warning that if I > > > update the kernel need too issue the following: > > > > > > vmware-modconfig --console --install-all > > > > > > so I ran this & tried to run vmplayer > > > this opened but crashed as soon as i tried to play a VM, I then > > > decided that as I had not used it for some time I would just remove > > > it: > > > > > > vmware-installer --uninstall-product vmware-player > > > > > > this finished & so I ran: > > > > > > pacman -R vmware-patch > > > > > > all was ok (so I thought) a while later I had to reboot to do > > > something in my win7 install (non volatile) upon completing I rebooted > > > back to arch & now my install refuses to boot & I see: > > > > > > Failed to start load Kernel Modules [FAILED] see 'systemctl status > > > systemd-modules-load.service' for details > > > > > > obviously systemd fall's over & offers to enter password or control-D > > > to continue > > > > > > well the system refuses to go any further & locks up totally (no > > > flashing kbd lights like a panic though!) > > > the exact same happens when I boot the fallback kernel > > > > > > I can chroot into it using the old media (CORE 2011.08.19) which is > > > the most recent I have, whilst chrooted in I thought perhaps the old > > > vmware modules did not get removed correctly so I blacklisted them in: > > > > > > /etc/modprobe.d/vmware.conf > > > > > > blacklist vmmon > > > [...] > > > > > > I have managed to get into the system using the following boot parameter: > > > > > > systemd.unit=rescue.target > > > > > > I then ran: > > > > > > systemctl status systemd-modules-load.service > > > > > > this provided the default message about the service not starting but > > > no reason why or what caused it to fail > > > > > > So any advice or way forward would be appreciated as I am totally lost > > > & have googled everything I can think of which may help but this is > > > the first time I have b0rk3d the modules & am lost as to what to do. > > > > > > -- > > > Regards > > > Thomas Rand > > > > Good to know, I use VMware on one install, thanks for posting this :) no worries glad my post has helped someone else :)
[arch-general] Setting prefered voice for espeakup
Hi, I was wondering if anyone can tell me how to set the default voice for espeakup? I have enabled the service file, which works great, and I have edited the file in /etc/conf.d/espeakup and added --default-voice=en-us to the args, but it still uses the default (UK) voice. Does anyone know what I am doing wrong? Thanks for the help Storm -- Registered Linux user number 508465: https://linuxcounter.net/user/508465.html My blog, Thoughts of a Dragon: http://www.stormdragon.us/ Do you get paid for tweeting? I do: http://spn.tw/r11uj "And for every crossing where two roads diverged. I fell one false decision. But still you find me on this earth." Van Canto - I Stand Alone
Re: [arch-general] [arch-dev-public] Dropping all packages with missing systemd units
Le Mon, 05 Nov 2012 18:44:18 +1000, Allan McRae a écrit : > On 02/11/12 12:46, Allan McRae wrote: > > > Not needed for anything so will be dumped soon...: > > snort > > tinc > > hpoj > > > Do the maintainers for any of these packages have any plans to fix > these? If there is not even a response saying it will be looked at in > the next couple of days, they will be removed. > > Allan > > Hi, Concerning tinc, a bug report [1] was created with an attached service file, which has been added to the 1.0.19-2 version of the package [2]. It seems that the TODO-list for missing systemd units has just not been updated for tinc yet. 1: https://bugs.archlinux.org/task/31456 2: https://projects.archlinux.org/svntogit/community.git/commit/trunk?h=packages/tinc&id=846fc3cac1a89e9275ee562efd6ab2c15aa3e386 -- Sébastien Leduc
[arch-general] USB Flash drive problems
Hi . Just purchased several SanDisk 4Gb Cruzer Blade USB flash drives but can not access any of them . the only error report i can find just says An error occurred while accessing `3.7GiB Removable Media`, the system responded: An unspecified error has occurred.: Not Authorized This happens both as user or root , any other non SanDisk flash drive is fine . I was hoping to put music on them for the car as the system incar can only read 4 Gb Max drives these seemed ideal look like they may bee a bummer . Any tips anyone .. Pete . -- Linux 7-of-9 3.6.4-1-ARCH #1 SMP PREEMPT Mon Oct 29 09:49:00 CET 2012 x86_64 GNU/Linux
Re: [arch-general] resume do not work after self suspend in gnome 3.6
Hi, On 2012-11-02 15:23, Mathieu R. wrote: Since the update to gnome 3.6, when my laptop goes to suspend 2 ram by have been ideling for 5 minutes, the resume does not work : i got a black screen with mouse cursor, and no way to log in GDM. I get the same problem after resume under Xfce, unless the screen is locked. The mouse cursor seems to see windows, as its shape changes when I move it, but I don't. I have to go to another TTY, restart gdm, and log in. I got to a text console, set $DISPLAY and launched xkill, in case the black background have been a window of some software. No effect (I probably killed a random application). I then sent the lock command to the screen saver. It took over the screen, I unlocked it, and I get back my screen with visible windows. So adding a hook to lock screen to /usr/lib/systemd/system-sleep and /etc/pm/sleep.d avoids the problem for me most of the time, even if that doesn't really solve it. I don't know whether Gnome screen saver will do the same for you, neither the command to activate it, but it's worth to try. On 2012-11-04 05:05, Martín Cigorraga wrote: what's your video card? $ lspci | grep -i vga will do it. I will answer for me: Advanced Micro Devices [AMD] nee ATI Radeon RV250 [Mobility FireGL 9000] (rev 01) (It's quite an old beast. On a more recent laptop with more or less the same configuration for the system, I don't have the same problem.) Also: 1. do you have installed acpi, laptop-mode-tools or pm-utils? All of them. 2. what does happen if you suspend your system using the pm-suspend tool? I works as described. On the other hand, suspend from systemd doesn't even success to suspend this laptop. Only hibernate works (with the famous black screen when waking up). A $ man pm-suspend will give you useful data about the quirks flags you can use. Tried pm-suspend --quirk-radeon-off with no more success. -- Laurent Dudouet
Re: [arch-general] [arch-dev-public] Dropping all packages with missing systemd units
On Mon, Nov 5, 2012 at 1:20 PM, Sébastien Leduc wrote: > Concerning tinc, a bug report [1] was created with an attached service > file, which has been added to the 1.0.19-2 version of the package [2]. > > It seems that the TODO-list for missing systemd units has just not been > updated for tinc yet. Good catch. I updated the TODO list. -t
Re: [arch-general] USB Flash drive problems
Can you use any other flash drives or removable devices? Which display manager do you use, and which file manager? I get this error several times due to added 'ck-launch-session' to my $HOME/.xinitrc because my display manager have already support this. 2012/11/5 P .NIKOLIC > Hi . > > Just purchased several SanDisk 4Gb Cruzer Blade USB flash drives but > can not access any of them . the only error report i can find just says > > An error occurred while accessing `3.7GiB Removable Media`, the system > responded: An unspecified error has occurred.: Not Authorized > > This happens both as user or root , any other non SanDisk flash drive > is fine . I was hoping to put music on them for the car as the system > incar can only read 4 Gb Max drives these seemed ideal look like they > may bee a bummer . > > Any tips anyone .. > > > Pete . > > > -- > Linux 7-of-9 3.6.4-1-ARCH #1 SMP PREEMPT Mon Oct 29 09:49:00 CET 2012 > x86_64 GNU/Linux > -- Regards, Administrator of Arch Linux Chinese Community Phoenix Nemo
Re: [arch-general] USB Flash drive problems
On Mon, Nov 5, 2012 at 1:32 PM, Phoenix Nemo wrote: > Can you use any other flash drives or removable devices? Which display > manager do you use, and which file manager? > > I get this error several times due to added 'ck-launch-session' to my > $HOME/.xinitrc because my display manager have already support this. Notice that consolekit is no longer supported, and should be removed. To get the equivalent functionality you should just boot with systemd. I don't know if this is relevant to OP's problem though. -t
[arch-general] Forking daemons and systemd
Hi, I was wondering whether there is a guideline regarding using Type=forking daemons in systemd units. For instance, if a daemon supports a cmdline switch to run in foreground isn't it better to use this argument in ExecStart? Personally, I was bitten by this with haveged.service which fails on shutdown and whose unit has Type=forking, but I also noticed that ntpd is allowed to fork. Both of them support foreground operation (haveged -F and ntpd -n respectively)? TIA, -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] Forking daemons and systemd
On Mon, Nov 5, 2012 at 5:01 PM, Leonid Isaev wrote: > I was wondering whether there is a guideline regarding using > Type=forking daemons in systemd units. For instance, if a daemon supports a > cmdline switch to run in foreground isn't it better to use this argument in > ExecStart? If you start the daemon in the foreground (i.e., use the default Type=simple), it means that systemd will consider it started immediately, and not wait for it to be initialized. In other words, it assumes that whatever communication channels (sockets) have been set up already and that the daemon supports being socket activated. If that is not the case, then services which are ordered after your service might start too early. Clearly, if you know that nothing will ever be ordered After= your service the above is not an issue, and you can use Type=simple without worrying. A better solution would be to patch the service to support Type=dbus/notify or to support socket activation. If that is out of the question, then Type=forking is the safest bet. This mode is a bit more fragile than the other ones, as it relies on systemd being able to figure out what is the main process. Specifying PIDFile= is advised if the daemon supports that. Though it depends on the daemon implementing that correctly. Most (all?) it works just fine :-) HTH, Tom
Re: [arch-general] Forking daemons and systemd
On Mon, Nov 05, 2012 at 10:01:11AM -0600, Leonid Isaev wrote: > Hi, > > I was wondering whether there is a guideline regarding using > Type=forking daemons in systemd units. For instance, if a daemon supports a > cmdline switch to run in foreground isn't it better to use this argument in > ExecStart? > Personally, I was bitten by this with haveged.service which fails on > shutdown and whose unit has Type=forking, but I also noticed that ntpd is > allowed to fork. Both of them support foreground operation (haveged -F and > ntpd -n respectively)? Essentially, it comes down to ordering of other daemons. It's always going to be some trifling amount faster to start a daemon in the foreground because systemd assumes it to be alive as soon as it starts. Conversely, a Type=forking daemon is only considered alive only once the parent process has exited. What this means is that while you might be able to start a daemon which normally forks in non-forking mode, you can't guarantee that daemons which rely on the non-forking daemon can be reliably started, since various listeners or other channels may not be established in time. The ideal solution is to implement sd_notify() and use Type=notify, or full blown socket activation should it be appropriate for the daemon. Both of these cases allow for essentially fire-and-forget style startup with guarantees of availability for ordering. Of course, if you don't think you ever need to order anything on a given daemon, then Type=simple is just fine. HTH, d
Re: [arch-general] USB Flash drive problems
My son-in-law recently purchased 2 of these & he could not access them on PS3 or my arch desktop. It turned out they were formatted as EXFAT, he re-formatted as NTFS & all was ok for him. What are yours formatted as? Also I have had similar issue's in the past & just re-formatted to FAT & all was ok. On Mon, Nov 05, 2012 at 01:40:21PM +0100, Tom Gundersen wrote: > On Mon, Nov 5, 2012 at 1:32 PM, Phoenix Nemo > wrote: > > Can you use any other flash drives or removable devices? Which display > > manager do you use, and which file manager? > > > > I get this error several times due to added 'ck-launch-session' to my > > $HOME/.xinitrc because my display manager have already support this. > > Notice that consolekit is no longer supported, and should be removed. > To get the equivalent functionality you should just boot with systemd. > I don't know if this is relevant to OP's problem though. > > -t
Re: [arch-general] USB Flash drive problems
On Mon, 5 Nov 2012 13:40:21 +0100 Tom Gundersen wrote: > On Mon, Nov 5, 2012 at 1:32 PM, Phoenix Nemo > wrote: > > Can you use any other flash drives or removable devices? Which > > display manager do you use, and which file manager? > > > > I get this error several times due to added 'ck-launch-session' to > > my $HOME/.xinitrc because my display manager have already support > > this. > > Notice that consolekit is no longer supported, and should be removed. > To get the equivalent functionality you should just boot with systemd. > I don't know if this is relevant to OP's problem though. > > -t This is possible ..from what i have been reading not too sure if i have Systemd running or not the system is fully updated . How do i check to see if it is systemd or not sorry to sound fick but got lots of other things on my mind as well right now .. Thanks Pete . -- Linux 7-of-9 3.6.5-1-ARCH #1 SMP PREEMPT Wed Oct 31 20:57:39 CET 2012 x86_64 GNU/Linux
Re: [arch-general] USB Flash drive problems
On Mon, 5 Nov 2012 13:40:21 +0100 Tom Gundersen wrote: > Notice that consolekit is no longer supported, and should be removed. > To get the equivalent functionality you should just boot with systemd. Or use udevil/spacefm I use custom udev rules and a script
Re: [arch-general] USB Flash drive problems
On Mon, Nov 5, 2012 at 7:22 PM, P .NIKOLIC wrote: > This is possible ..from what i have been reading not too sure if i > have Systemd running or not the system is fully updated . You will not have been converted over automatically. See the wiki for how to do that. > How do i check to see if it is systemd or not sorry to sound fick but > got lots of other things on my mind as well right now .. I guess running "systemctl" should tell you? If you are using systemd it will list a lot of running services. Otherwise I assume it will return a dbus error (but I haven't tried that myself, so only a guess). -t
Re: [arch-general] USB Flash drive problems
> > I guess running "systemctl" should tell you? If you are using systemd > it will list a lot of running services. Otherwise I assume it will > return a dbus error (but I haven't tried that myself, so only a > guess). > > FYI, I haven't updated to systemd yet and the error when running systemctl reads: Failed to get D-Bus connection: No connection to service manager.
Re: [arch-general] USB Flash drive problems
On 6 November 2012 02:50, Squall Lionheart wrote: >> >> I guess running "systemctl" should tell you? If you are using systemd >> it will list a lot of running services. Otherwise I assume it will >> return a dbus error (but I haven't tried that myself, so only a >> guess). >> >> > FYI, I haven't updated to systemd yet and the error when running systemctl > reads: > Failed to get D-Bus connection: No connection to service manager. Yes, that is correct behaviour, and means you're not running systemd. I believe a valid logind session needs to exist for these to work, and that means booting with systemd. -- GPG/PGP ID: C0711BF1
Re: [arch-general] USB Flash drive problems
On Mon, 5 Nov 2012 17:18:48 +0200 Tom Rand wrote: > My son-in-law recently purchased 2 of these & he could not access > them on PS3 or my arch desktop. > It turned out they were formatted as EXFAT, he re-formatted as NTFS & > all was ok for him. > > What are yours formatted as? > > Also I have had similar issue's in the past & just re-formatted to > FAT & all was ok. Hi Tom . Been there using the laptop that is not as upto date and completely redid the partition and formatted one of them vfat still the same on this machine but ok on the laptop . I need to keep them vfat as they are actually for use in the car it takes mp3's on usb drives (max 4Gb) and only read vfat (and only mp3 not ogg) Pete . -- Linux 7-of-9 3.6.5-1-ARCH #1 SMP PREEMPT Wed Oct 31 20:57:39 CET 2012 x86_64 GNU/Linux
Re: [arch-general] USB Flash drive problems
On Tue, Nov 06, 2012 at 03:23:25AM +0800, Rashif Ray Rahman wrote: > On 6 November 2012 02:50, Squall Lionheart wrote: > >> > >> I guess running "systemctl" should tell you? If you are using systemd > >> it will list a lot of running services. Otherwise I assume it will > >> return a dbus error (but I haven't tried that myself, so only a > >> guess). > >> > >> > > FYI, I haven't updated to systemd yet and the error when running systemctl > > reads: > > Failed to get D-Bus connection: No connection to service manager. > > Yes, that is correct behaviour, and means you're not running systemd. > I believe a valid logind session needs to exist for these to work, and > that means booting with systemd. Just to be clear, the logind session isn't needed -- systemd's private socket needs to be available, meaning /run/systemd/private exists. d
Re: [arch-general] USB Flash drive problems
On Mon, 5 Nov 2012 19:42:20 +0100 Tom Gundersen wrote: > On Mon, Nov 5, 2012 at 7:22 PM, P .NIKOLIC > wrote: > > This is possible ..from what i have been reading not too sure if i > > have Systemd running or not the system is fully updated . > > You will not have been converted over automatically. See the wiki for > how to do that. > > > How do i check to see if it is systemd or not sorry to sound fick > > but got lots of other things on my mind as well right now .. > > I guess running "systemctl" should tell you? If you are using systemd > it will list a lot of running services. Otherwise I assume it will > return a dbus error (but I haven't tried that myself, so only a > guess). > > -t Hi Tom .. Right so a reply of Failed to get D-Bus connection: No connection to service manager i take it means no I will start a new thread i think to get systemd running .. Pete . -- Linux 7-of-9 3.6.5-1-ARCH #1 SMP PREEMPT Wed Oct 31 20:57:39 CET 2012 x86_64 GNU/Linux
Re: [arch-general] USB Flash drive problems
Am Montag, den 05.11.2012, 18:22 + schrieb P .NIKOLIC: > How do i check to see if it is systemd or not $ printf "%d" `systemd-notify --booted` man systemd-notify: “[…] --booted Returns 0 if the system was booted up with systemd, non-zero otherwise. […]”
Re: [arch-general] Problem Printing with Inkscape
On Sat, Nov 03, 2012 at 10:30:53AM -0400, David Stephenson wrote: > I'm having problems printing from Inkscape. I have libcups, cups-filters, > avahi, ghostscript, gsfonts, samba, hplip, and hpoj installed. My printer > is a HP LaserJet M2727nf MFP. > > I'm currently using the Postscript driver. Printing from most programs > works fine - but when attempting to print from inkscape, the job fails and > CUPS gives me a "filter failed" error. > > When using hpijs, attempting to print from Inkscape results in a blank > printed page with the text "Error: /typecheck in --run-- / Operand Stack: / > --dict:6/15(L)-- 1 11 Annots/E" > > What can I do to address this? What other information can I provide? I have never managed to print directly from Inkscape. I resort to saving as a pdf then printing that. Rgds, -- Mike Bishop Willow, Alaska
Re: [arch-general] USB Flash drive problems
>On Mon, 5 Nov 2012 18:22:32 + >"P .NIKOLIC" wrote: > > How do i check to see if it is systemd or not sorry to sound fick but > got lots of other things on my mind as well right now .. > > > Thanks Pete . > > cat /proc/1/comm that should return systemd or init. --timttmy
Re: [arch-general] USB Flash drive problems
On Mon, Nov 05, 2012 at 08:22:33PM +0100, coderkun wrote: > Am Montag, den 05.11.2012, 18:22 + schrieb P .NIKOLIC: > > How do i check to see if it is systemd or not > > $ printf "%d" `systemd-notify --booted` systemd-notify doesn't print anything. If you really want to print something: $ systemd-notify --booted && echo "booted on systemd" or $ systemd-notify --booted; echo $? > > man systemd-notify: > “[…] > --booted > Returns 0 if the system was booted up with systemd, non-zero otherwise. > […]” > Note the "returns", not "prints". d
Re: [arch-general] Forking daemons and systemd
On Mon, 5 Nov 2012 11:18:48 -0500 Dave Reisner wrote: > On Mon, Nov 05, 2012 at 10:01:11AM -0600, Leonid Isaev wrote: > > Hi, > > > > I was wondering whether there is a guideline regarding using > > Type=forking daemons in systemd units. For instance, if a daemon supports a > > cmdline switch to run in foreground isn't it better to use this argument in > > ExecStart? > > Personally, I was bitten by this with haveged.service which fails > > on shutdown and whose unit has Type=forking, but I also noticed that ntpd > > is allowed to fork. Both of them support foreground operation (haveged -F > > and ntpd -n respectively)? > > Essentially, it comes down to ordering of other daemons. > > It's always going to be some trifling amount faster to start a daemon in > the foreground because systemd assumes it to be alive as soon as it > starts. Conversely, a Type=forking daemon is only considered alive only > once the parent process has exited. > > What this means is that while you might be able to start a daemon which > normally forks in non-forking mode, you can't guarantee that daemons > which rely on the non-forking daemon can be reliably started, since > various listeners or other channels may not be established in time. > > The ideal solution is to implement sd_notify() and use Type=notify, or > full blown socket activation should it be appropriate for the daemon. > Both of these cases allow for essentially fire-and-forget style startup > with guarantees of availability for ordering. > > Of course, if you don't think you ever need to order anything on a given > daemon, then Type=simple is just fine. > > HTH, > d Aha... thanks for the clarification. I'm pretty sure that havege does not open any sockets/has to be a dependency of anything, but ntpd I'll have to check. -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] Forking daemons and systemd
On Mon, Nov 05, 2012 at 02:37:15PM -0600, Leonid Isaev wrote: > On Mon, 5 Nov 2012 11:18:48 -0500 > Dave Reisner wrote: > > > On Mon, Nov 05, 2012 at 10:01:11AM -0600, Leonid Isaev wrote: > > > Hi, > > > > > > I was wondering whether there is a guideline regarding using > > > Type=forking daemons in systemd units. For instance, if a daemon supports > > > a > > > cmdline switch to run in foreground isn't it better to use this argument > > > in > > > ExecStart? > > > Personally, I was bitten by this with haveged.service which fails > > > on shutdown and whose unit has Type=forking, but I also noticed that ntpd > > > is allowed to fork. Both of them support foreground operation (haveged -F > > > and ntpd -n respectively)? > > > > Essentially, it comes down to ordering of other daemons. > > > > It's always going to be some trifling amount faster to start a daemon in > > the foreground because systemd assumes it to be alive as soon as it > > starts. Conversely, a Type=forking daemon is only considered alive only > > once the parent process has exited. > > > > What this means is that while you might be able to start a daemon which > > normally forks in non-forking mode, you can't guarantee that daemons > > which rely on the non-forking daemon can be reliably started, since > > various listeners or other channels may not be established in time. > > > > The ideal solution is to implement sd_notify() and use Type=notify, or > > full blown socket activation should it be appropriate for the daemon. > > Both of these cases allow for essentially fire-and-forget style startup > > with guarantees of availability for ordering. > > > > Of course, if you don't think you ever need to order anything on a given > > daemon, then Type=simple is just fine. > > > > HTH, > > d > > Aha... thanks for the clarification. I'm pretty sure that havege does not > open any sockets/has to be a dependency of anything, but ntpd I'll have to > check. It isn't just side effects which are a concern -- it might be the facility being provided that you want to wait on. Using part of your own example, you might not want to start your mail daemon before ntpd has run, to ensure proper timestamping. There's even a 'time-sync.target' documented by systemd.special(7) which one might want to order on, making ntpd's startup more important. d
Re: [arch-general] Systemd and inactive sessions
On 11/01/2012 06:47 PM, Leonid Isaev wrote: On Thu, 01 Nov 2012 22:57:41 +0100 Thomas Bächler wrote: The session doesn't get removed completely until all processes belonging to it's cgroup have closed on their own. See man logind.conf, search for 'KillUserProcesses'. OK, changed to 'yes' to avoid future confusion... Loving the support :) Important caveat to that setting: "Note that setting KillUserProcesses=1 will break tools like screen(1)" DR
Re: [arch-general] Systemd and inactive sessions
On Mon, 05 Nov 2012 16:21:21 -0500 David Rosenstrauch wrote: > On 11/01/2012 06:47 PM, Leonid Isaev wrote: > > On Thu, 01 Nov 2012 22:57:41 +0100 > > Thomas Bächler wrote: > >>> The session doesn't get removed completely until all processes belonging > >>> to it's cgroup have closed on their own. > >> > >> See man logind.conf, search for 'KillUserProcesses'. > >> > > > > OK, changed to 'yes' to avoid future confusion... Loving the support :) > > Important caveat to that setting: > > "Note that setting KillUserProcesses=1 will break tools like screen(1)" > > DR > Yes, I learnt that the hard way :) So it's a useful setting for a laptop, but obviously not for a server... -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature
Re: [arch-general] Forking daemons and systemd
I used type=forking in my espeakup unit. From what I'm reading, it looks like that was actually unnecessary, since a. espeakup is not a dependency of any other service, as it only provides speech feedback for blind users at boot time, and b. the daemon supports a pidfile, which I included in the service unit. I can test this on my local unit file, or I can pull the edited version from testing to be sure it works correctly in most if not all cases. ~Kyle http://kyle.tk -- Linux killed Kenny, bastard! --Subject of a real e-mail to the Linux kernel mailing list 12 January, 2009
Re: [arch-general] Forking daemons and systemd
On Mon, Nov 5, 2012 at 10:48 PM, Kyle wrote: > a. espeakup is not a dependency of any other service, as it only provides > speech feedback for blind users at boot time, and > b. the daemon supports a pidfile, which I included in the service unit. > I can test this on my local unit file, or I can pull the edited version from > testing to be sure it works correctly in most if not all cases. I think in this case it makes sense to use Type=forking (especially as there is a PIDFile, so this will likely work well). I can imagine wanting to start something only after espeakup is up, even if that is not the case at the moment. -t
Re: [arch-general] Forking daemons and systemd
According to Tom Gundersen: # I think in this case it makes sense to use Type=forking (especially as # there is a PIDFile, so this will likely work well). I can imagine # wanting to start something only after espeakup is up, even if that is # not the case at the moment. Oh, so forking wasn't the issue with my file, only the location of the pidfile. I see I somehow forgot about the change from /var/run to /run. I guess I didn't catch it when I copied its location from the initscript. I'll run a test, as I now have the new file, but I see no reason why it wouldn't be usable or work as expected. Sorry I wasn't able to test sooner, as I had other things going on over the past week. ~Kyle http://kyle.tk -- Linux killed Kenny, bastard! --Subject of a real e-mail to the Linux kernel mailing list 12 January, 2009
Re: [arch-general] Problem Printing with Inkscape
Please report this as a bug directly to the Inkscape developers, if it isn't reported already. If it's not a bug in Inkscape itself, but one of the subsystems, they will know where to direct the report, possibly with useful additional information. http://inkscape.org/report_bugs.php -- Best regards, Alexander Rødseth xyproto / TU
Re: [arch-general] Forking daemons and systemd
According to Kyle: # I'll run a test, as I now have the new file, but I see no reason why it # wouldn't be usable or work as expected. Tested and it works perfectly. Thanks for getting this in, and sorry for taking this thread for a little bit of a ride into the land of OT. ~Kyle http://kyle.tk -- Linux killed Kenny, bastard! --Subject of a real e-mail to the Linux kernel mailing list 12 January, 2009
