Re: [systemd-devel] systemd[725]: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted

2013-07-06 Thread Marc-Antoine Perennou 
The patch I mailed a few hours ago about chowning cgroups solved this issue
here.


On 6 July 2013 05:57, Kok, Auke-jan H auke-jan.h@intel.com wrote:

 On Thu, Jul 4, 2013 at 6:30 PM, Kay Sievers k...@vrfy.org wrote:
  On Fri, Jul 5, 2013 at 2:35 AM, Cristian Rodríguez
  crrodrig...@opensuse.org wrote:
  Since systemd 205, Im getting this scary warning
 
  Jul 04 19:55:36 xps9000.cristianrodriguez.net systemd[1]: Starting
  user-1000.slice.
 
  Jul 04 19:55:36 xps9000.cristianrodriguez.net systemd[1]: Created slice
  user-1000.slice.
 
  Jul 04 19:55:36 xps9000.cristianrodriguez.net systemd[1]: Starting User
  Manager for 1000...
 
  Jul 04 19:55:36 xps9000.cristianrodriguez.net systemd[1]: Starting
 Session 1
  of user crrodriguez.
 
  Jul 04 19:55:36 xps9000.cristianrodriguez.net systemd-logind[423]: New
  session 1 of user crrodriguez.
 
  Jul 04 19:55:36 xps9000.cristianrodriguez.net systemd-logind[423]:
 Linked
  /tmp/.X11-unix/X0 to /run/user/1000/X11-display.
 
  Jul 04 19:55:36 xps9000.cristianrodriguez.net systemd[1]: Started
 Session 1
  of user crrodriguez.
 
  Jul 04 19:55:36 xps9000.cristianrodriguez.net systemd[725]: Failed at
 step
  PAM spawning /usr/lib/systemd/systemd: Operation not permitted
 
  We are just not there, systemd --user is not started at the moment,
  the cgroup sub-tree for the user's session is not accessible for the
  systemd --user process running under the user's uid.
 
  Nothing really to worry about, the message should be ignored for now,
  we will get there soon ...

 does the old method of manually starting user@.service at least still
 work? I haven't had any time to track the latest release yet...

 Auke
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Setting Up SSH Tunnels

2013-07-06 Thread CACook 


Reindl, thanks again for your help yesterday.  I have hassled for years 
with my unreliable method of setting up the SSH tunnels.



Reindl Harald:

with the small script below i see the status of all forwarding-services
including all ssh processes with their params and the last restart-time

what more does someone need to manage this out-of-the-box?


cat /usr/local/bin/forwardings.sh
#!/usr/bin/bash
if [ $1 ==  ]; then
  ACTION=status
else

  ACTION=$1
fi

/usr/bin/systemctl $ACTION forward-host1.service 
forward-host2.service...


I fiddled with this, trying to strip down the information to what is 
absolutely necessary, but then I realized that all I ever want to know 
is whether the port is open.


I propose a different approach, one which directly checks to see whether 
the tunneled port is actually being listened to.  This is my script:

--
#!/usr/bin/bash

echo -n Squid  lsof -i -n -P |grep 3128 (LISTEN)
echo -n Cups   lsof -i -n -P |grep 631 (LISTEN)
echo -n Mysql  lsof -i -n -P |grep 22306 (LISTEN)
echo -n Myth43 lsof -i -n -P |grep 6543 (LISTEN)
echo -n Myth44 lsof -i -n -P |grep 6544 (LISTEN)
echo -n Sane   lsof -i -n -P |grep 6566 (LISTEN)
echo -n Tor9151 lsof -i -n -P |grep 9151 (LISTEN)
echo -n Tor9152 lsof -i -n -P |grep 9152 (LISTEN)
echo -n Tor9153 lsof -i -n -P |grep 9153 (LISTEN)
echo -n Tor9154 lsof -i -n -P |grep 9154 (LISTEN)
echo -n Tor9155 lsof -i -n -P |grep 9155 (LISTEN)
echo -n Tor9156 lsof -i -n -P |grep 9156 (LISTEN)
echo -n Tor9157 lsof -i -n -P |grep 9157 (LISTEN)
echo -n Tor9158 lsof -i -n -P |grep 9158 (LISTEN)
echo -n Tor9159 lsof -i -n -P |grep 9159 (LISTEN)
echo -n Tor9160 lsof -i -n -P |grep 9160 (LISTEN)
echo -n Tor9161 lsof -i -n -P |grep 9161 (LISTEN)
echo -n Tor9162 lsof -i -n -P |grep 9162 (LISTEN)
echo -n Tor9163 lsof -i -n -P |grep 9163 (LISTEN)
echo -n Tor9164 lsof -i -n -P |grep 9164 (LISTEN)
echo -n Tor9165 lsof -i -n -P |grep 9165 (LISTEN)

echo
--

Only problem is, if a port is not listening it glitches the display 
since I use -n.








___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Failed to destroy cgroup /system.slice/plymouth-start.service: Device or resource busy

2013-07-06 Thread Cristian Rodríguez 

Hi:

With v205, I sometimes get at boot time:

Failed to destroy cgroup /system.slice/plymouth-start.service: Device or 
resource busy


void unit_destroy_cgroup(Unit *u) {..

r = cg_trim_with_mask(u-cgroup_mask, u-cgroup_path, true); ...

calls:

cg_trim(SYSTEMD_CGROUP_CONTROLLER, path, delete_root); --delete_root is 
true..


int cg_trim(const char *controller, const char *path, bool delete_root) {
...

if (delete_root) {
if (rmdir(fs)  0  errno != ENOENT) -- here rmdir() fails with 
EBUSY because path is currently in use..

   return -errno;
}






___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel