Добрый день, у меня два месяца уже пропадает интернет, сам включается и выключается, звонил провайдеру все нормально, поменял роутер, и так же сетуация, тут зашел в журнал событий и выдает такой лог, это нормально?
Jan 1 00:00:07 kernel: 867x ver = Q, (0412 ver)=0x63330000, (ver)=0x3200
Jan 1 00:00:07 libshared rtl:start_wifi[41]: begin
Jan 1 00:00:07 start_wifi[41]: start on br= br0
Jan 1 00:00:07 sched_set_task_activity[41]: Cannot open pipe
Jan 1 00:00:07 DMS_NL_API[41]: Rtnetlink answer: Success
Jan 1 00:00:07 DMS_ROUTE_SUCCESS[41]: ADD 239.255.255.250 via (null) dev br0 metr 0 table 254 (configure_config_file)
Jan 1 00:00:07 start_wifi[41]: pin = 73194378
Jan 1 00:00:07 config_ssid_params[41]: begin
Jan 1 00:00:07 config_ssid_params[41]: ifname = wlan0
Jan 1 00:00:07 get_gr_name_by_lan_key[41]: start
Jan 1 00:00:07 get_gr_name_by_lan_key[41]: wlan0: br0
Jan 1 00:00:07 start_wifi[41]: Starting iwcontrol…
Jan 1 00:00:07 kernel: device wlan0 entered promiscuous mode
Jan 1 00:00:08 kernel: Time_elapse(1) = 1150
Jan 1 00:00:08 kernel: Time_elapse@sendtimer = 1150
Jan 1 00:00:10 update_ipfilters[41]: error in params
Jan 1 00:00:10 kernel: Fast path for http trafic Enable
Jan 1 00:00:10 calculate_file_md5sum[41]: Error: can’t open file /tmp/dnsmasq.conf
Jan 1 00:00:10 recheck_dnsmasq[41]: MD5 sums of /tmp/dnsmasq.conf cannot be calculated, restarting DNSMASQ
Jan 1 00:00:10 resident[41]: init wan
Jan 1 00:00:10 get_gr_name_by_l3_key[41]: start
Jan 1 00:00:10 get_gr_name_by_l3_key[41]: br0
Jan 1 00:00:10 get_gr_name_by_l3_key[41]: start
Jan 1 00:00:10 get_gr_name_by_l3_key[41]: br0
Jan 1 00:00:11 pppoe-relay[194]: [truncated] m
Jan 1 00:00:11 dms_srv_httpd_start[41]: start
Jan 1 00:00:13 telnet-start[41]: begin…
Jan 1 00:00:13 telnet-start[41]: running on 23 port
Jan 1 00:00:13 telnet-start[41]: succes!
Jan 1 00:00:13 anweb[203]: Starting…
Jan 1 00:00:13 start_tr069_with_args[41]: start success with new pid 207
Jan 1 00:00:13 recheck_dnsmasq[41]: MD5 sums of /tmp/dnsmasq.conf are equal, not restarting DNSMASQ
Jan 1 00:00:14 link_watcher_start[41]: link watcher start with status -1
Jan 1 00:00:14 resident[41]: Out init_device
Jan 1 00:00:15 resident_mng[40]: RESIDENT WORKER is running.
Jan 1 00:00:15 anweb[203]: anweb sighandler signal = 126
Jan 1 00:00:15 anweb[203]: HTTP main server started on 80,443s port (ports).
Jan 1 00:00:15 anweb[203]: HTTP intercept server started on 81,4445s port (ports).
Jan 1 00:00:15 resident_phy_link_handler[232]: record = phy:4;status:1
Jan 1 00:00:15 resident_phy_link_handler[232]: phy — 4, status — 1
Jan 1 00:00:15 resident_phy_link_handler[231]: record = phy:3;status:0
Jan 1 00:00:15 resident_phy_link_handler[231]: phy — 3, status — 0
Jan 1 00:00:15 dms_link_watch_lock[231]: Semaphore creation error 17 (File exists)
Jan 1 00:00:15 resident_phy_link_handler[230]: record = phy:2;status:0
Jan 1 00:00:15 resident_phy_link_handler[230]: phy — 2, status — 0
Jan 1 00:00:15 dms_link_watch_lock[230]: Semaphore creation error 17 (File exists)
Jan 1 00:00:15 resident_phy_link_handler[229]: record = phy:1;status:0
Jan 1 00:00:15 resident_phy_link_handler[229]: phy — 1, status — 0
Jan 1 00:00:15 dms_link_watch_lock[229]: Semaphore creation error 17 (File exists)
Jan 1 00:00:15 resident_phy_link_handler[232]: Exit
Jan 1 00:00:15 resident_phy_link_handler[231]: Exit
Jan 1 00:00:15 resident_phy_link_handler[230]: Exit
Jan 1 00:00:15 resident_phy_link_handler[229]: Exit
Jan 1 00:00:16 main[216]: reboot_timeout_stop(-1)
Jan 1 00:00:16 main[216]: reboot_timeout_stop(-1)
Jan 1 00:00:16 main[216]: reboot_timeout_stop(-1)
Jan 1 00:00:16 main[216]: reboot_timeout_stop(-1)
Jan 1 00:00:16 main[216]: reboot_timeout_stop(-1)
Jan 1 00:00:16 kernel: br0: port 4(eth0.5) entering forwarding state
Jan 1 00:00:16 kernel: br0: port 3(eth0.4) entering forwarding state
Jan 1 00:00:16 kernel: br0: port 2(eth0.3) entering forwarding state
Jan 1 00:00:16 kernel: br0: port 1(eth0.2) entering forwarding state
Jan 1 00:00:17 save config[298]: saving… at line 176
Jan 1 00:00:17 write[298]: line 1321
Jan 1 00:00:17 save_to_flash[298]: file size is 3469
Jan 1 00:00:17 save config[298]: saving… at line 197
Jan 1 00:00:18 kernel: SachemAccess::reset()
Jan 1 00:00:18 kernel: 8676S ctrlin readback: afe version = 0x 3430
Jan 1 00:00:18 kernel: AFE_ver=0x686
Jan 1 00:00:18 kernel: 8676(>M) + 6256/6257 decide use DDR mode
Jan 1 00:00:18 kernel: xtm_elapse() = 11230
Jan 1 00:00:18 kernel: LD Power down to avoid huge current
Jan 1 00:00:18 kernel: TxIdxTxIdx = 0
Jan 1 00:00:18 kernel: OKnum=512
Jan 1 00:00:18 kernel: DDR phase 0xd OK
Jan 1 00:00:18 kernel: OKnum=36
Jan 1 00:00:18 kernel: OKnum=19
Jan 1 00:00:18 kernel: OKnum=36
Jan 1 00:00:23 kernel: Time_elapse(2) = 16370
Jan 1 00:00:23 kernel: SachemAccess::reset()
Jan 1 00:00:27 kernel: SachemAccess::reset()
Jan 1 00:00:27 kernel: [br_handle_frame_finish 447]tmpOp=2.
Jan 1 00:00:27 kernel: [br_handle_frame_finish 447]tmpOp=1.
Jan 1 00:00:27 kernel: [br_handle_frame_finish 447]tmpOp=2.
Jan 1 00:00:27 kernel: [br_handle_frame_finish 447]tmpOp=1.
Jan 1 00:00:27 kernel: [br_handle_frame_finish 447]tmpOp=1.
Jan 1 00:00:28 kernel: SachemAccess::reset()
Jan 1 00:00:29 kernel: SachemAccess::reset()
Jan 1 00:00:31 kernel: SachemAccess::reset()
Jan 1 00:00:31 kernel: SachemAccess::reset()
Jan 1 00:00:33 kernel: SachemAccess::reset()
Jan 1 00:00:33 kernel: xtm_elapse() = 25870
Jan 1 00:00:33 kernel: LD Power down to avoid huge current
Jan 1 00:00:33 kernel: TxIdxTxIdx = 0
Jan 1 00:00:33 kernel: OKnum=512
Jan 1 00:00:33 kernel: DDR phase 0xd OK
Jan 1 00:00:33 kernel: OKnum=34
Jan 1 00:00:33 kernel: OKnum=21
Jan 1 00:00:33 kernel: OKnum=32
Jan 1 00:00:33 kernel: Final DDR phase auto select 13,forceDdrRxPhaseEdge=-1,forceDdrTxPhaseEdge=-1
Jan 1 00:00:33 kernel: LD Power On at end of DDR autoK
Jan 1 00:00:38 kernel: Time_elapse(3) = 31010
Jan 1 00:00:38 kernel: SachemAccess::reset()
Jan 1 00:00:39 kernel: SachemAccess::reset()
Jan 1 00:01:00 update_ntpclient[457]: start
Jan 1 00:01:00 update_ntpclient[457]: server string: ntpd -S /sbin/ntpevent -p pool.ntp.org&
Jan 1 03:01:09 kernel: ATM OAM F5 initialized.
Jan 1 03:01:09 kernel: ATM OAM F4 initialized.
Jan 1 03:01:09 kernel: Enable 8671G 1 function
Jan 1 03:01:09 kernel: Enable 8671 0 function
Jan 1 03:01:09 kernel: Enable 8672 function
Jan 1 03:01:09 kernel: applying workaround…done
Jan 1 03:01:09 kernel: Upstream Rate : 509 Kbps (line rate : 656)
Jan 1 03:01:09 kernel: Downstream Rate : 511 Kbps (line rate : 716)
Jan 1 03:01:18 resident[504]: resident_adsl_link_handler start!!!
Jan 1 03:01:18 resident[504]: record = type:atm
Jan 1 03:01:18 rlx_modem[504]: create atm start!!!
Jan 1 03:01:18 rlx_modem[504]: atmnum=1
Jan 1 03:01:18 rlx_modem[504]: cmd sarctl pvcnumber 1!!!
Jan 1 03:01:18 kernel: sar_ioctl: called. cmd=0x8a05, arg=7ff4388c
Jan 1 03:01:18 kernel: PVC Number = 1. Set Desc number per VC = 126
Jan 1 03:01:18 rlx_modem[504]: cmd mpoactl add vc0 pvc 8.35 encaps 1 qos ubr:pcr=6000!!!
Jan 1 03:01:18 syslog: Interface «vc0» created sucessfully
Jan 1 03:01:18 syslog: Communicating over ATM 0.8.35, encapsulation: 1
Jan 1 03:01:18 kernel: fixme atm_find_ci in sar_open!
Jan 1 03:01:18 kernel: (itf 0): open 8.35
Jan 1 03:01:18 kernel: create: ch0 (8/35) 6000,0
Jan 1 03:01:18 kernel: ATM OAM F5 initialized.
Jan 1 03:01:18 kernel: ATM OAM F4 initialized.
Jan 1 03:01:18 kernel: Enable 8671G 1 function
Jan 1 03:01:18 kernel: Enable 8671 0 function
Jan 1 03:01:18 kernel: Enable 8672 function
Jan 1 03:01:18 kernel: create: ch0 (8/35) 6000,0
Jan 1 03:01:18 kernel: net_device: 2175891456
Jan 1 03:01:18 kernel: applying workaround…done
Jan 1 03:01:18 syslog: Interface configured
Jan 1 03:01:18 kernel: sar_ioctl: called. cmd=0x8a08, arg=817fbb88
Jan 1 03:01:18 kernel: sar_ioctl: called. cmd=0x8a0f, arg=00415008
Jan 1 03:01:18 kernel: sar_ioctl: SAR_SET_SARHDR called.
Jan 1 03:01:18 kernel: vpi=8, vci = 35
Jan 1 03:01:18 kernel: Set CH 0 PPPoE mode on CKS register
Jan 1 03:01:18 kernel: sar_ioctl: SAR_SET_SARHDR done.
Jan 1 03:01:18 kernel: sar_ioctl: called. cmd=0x8a10, arg=(null)
Jan 1 03:01:18 rlx_modem[504]: mpoactl set vc0 vlan 0 vid 0 vprio 0
Jan 1 03:01:18 rlx_modem[504]: ifconfig vc0 mtu 1500
Jan 1 03:01:19 start_stop_wan_link_on_l2[504]: start with iface: vc0, status: 1
Jan 1 03:01:19 resident[504]: start ipoe
Jan 1 03:01:19 before_start_ip[504]:
Jan 1 03:01:19 start_ip[504]: begin (vc0 -> vc0_1)
Jan 1 03:01:19 resident[504]: start ipoe (v0) on vc0
Jan 1 03:01:19 start_ip[504]: pos = 9
Jan 1 03:01:19 start_stop_wan_link_on_l2[504]: End iface: vc0, status: 1
Jan 1 03:01:19 rlx_modem[504]: create atm start!!!
Jan 1 03:01:19 rlx_modem[504]: atmnum=2
Jan 1 03:01:19 rlx_modem[504]: cmd sarctl pvcnumber 2!!!
Jan 1 03:01:19 kernel: sar_ioctl: called. cmd=0x8a05, arg=7fd41bac
Jan 1 03:01:19 kernel: PVC Number = 2. Set Desc number per VC = 126
Jan 1 03:01:19 rlx_modem[504]: cmd mpoactl add vc1 pvc 0.33 encaps 1 qos ubr:pcr=6000!!!
Jan 1 03:01:19 syslog: Interface «vc1» created sucessfully
Jan 1 03:01:19 syslog: Communicating over ATM 0.0.33, encapsulation: 1
Jan 1 03:01:19 kernel: fixme atm_find_ci in sar_open!
Jan 1 03:01:19 kernel: (itf 0): open 0.33
Jan 1 03:01:19 kernel: create: ch1 (0/33) 6000,0
Jan 1 03:01:19 kernel: ATM OAM F5 initialized.
Jan 1 03:01:19 kernel: ATM OAM F4 initialized.
Jan 1 03:01:20 kernel: Enable 8671G 1 function
Jan 1 03:01:20 kernel: Enable 8671 0 function
Jan 1 03:01:20 kernel: Enable 8672 function
Jan 1 03:01:20 kernel: create: ch0 (8/35) 6000,0
Jan 1 03:01:20 kernel: net_device: 2175891456
Jan 1 03:01:20 kernel: create: ch1 (0/33) 6000,0
Jan 1 03:01:20 kernel: net_device: 2173857792
Jan 1 03:01:20 kernel: applying workaround…done
Jan 1 03:01:20 kernel: sar_ioctl: called. cmd=0x8a0f, arg=00415008
Jan 1 03:01:20 kernel: sar_ioctl: SAR_SET_SARHDR called.
Jan 1 03:01:20 kernel: vpi=0, vci = 33
Jan 1 03:01:20 kernel: Set CH 1 PPPoE mode on CKS register
Jan 1 03:01:20 kernel: sar_ioctl: SAR_SET_SARHDR done.
Jan 1 03:01:20 syslog: Interface configured
Jan 1 03:01:20 kernel: sar_ioctl: called. cmd=0x8a08, arg=817fbb88
Jan 1 03:01:20 kernel: sar_ioctl: called. cmd=0x8a10, arg=(null)
Jan 1 03:01:20 rlx_modem[504]: mpoactl set vc1 vlan 0 vid 0 vprio 0
Jan 1 03:01:20 rlx_modem[504]: ifconfig vc1 mtu 1500
Jan 1 03:01:20 udhcpc[535]: UDHCP start..
Jan 1 03:01:20 udhcpc[535]: udhcp client (v0.9.
started (iface: vc0, connect: 1)
Jan 1 03:01:20 udhcpc[535]: interface vc0 index 19
Jan 1 03:01:20 udhcpc[535]: interface vc0 hwaddr 1c:5f:2b:5a:9b:f2
Jan 1 03:01:20 udhcpc[535]: interface vc0 mtu is 1500
Jan 1 03:01:20 udhcpc[567]: execle’ing /tmp/udhcpc with name deconfig
Jan 1 03:01:20 event[567]: send event «ipoe down»
Jan 1 03:01:20 resident[216]: record = action:down;iface:vc0;contag:1;
Jan 1 03:01:20 udhcpc[535]: Opening raw socket on ifindex 19
Jan 1 03:01:20 udhcpc[535]: Sending discover…
Jan 1 03:01:20 resident[216]: phys_iface vc0
Jan 1 03:01:20 resident_ipoe_handler[216]: ip_type = <null>
Jan 1 03:01:20 resident[216]: resident_ipoe_handler — Set default type: ipv4
Jan 1 03:01:20 resident[216]: phys_iface vc0
Jan 1 03:01:20 resident[216]: resident_ipoe_handler — 2
Jan 1 03:01:20 resident_ipoe_handler[216]: name: vc0_1
Jan 1 03:01:21 start_stop_wan_link_on_l2[504]: start with iface: vc1, status: 1
Jan 1 03:01:21 start_pppd[504]: start pppd on vc1_1
Jan 1 03:01:21 stop_pppd[504]: stop pppd on vc1_1
Jan 1 03:01:21 resident[504]: set lock on vc1_1, with «/var/lock/vc1_1.lock»
Jan 1 03:01:21 wan_down[504]: name = ppp0
Jan 1 03:01:21 update_wan_firewall[504]: firewall enable
Jan 1 03:01:21 get_gr_name_by_l3_key[504]: start
Jan 1 03:01:21 get_gr_name_by_l3_key[504]: br0
Jan 1 03:01:21 get_gr_index[504]: gr=|0|
Jan 1 03:01:21 DMS_NL_API[504]: Rtnetlink answer: No such process
Jan 1 03:01:21 DMS_ROUTE_ERROR[504]: DEL default via (null) dev (null) metr 0 table 254 (wan_iptables_rules)
Jan 1 03:01:21 rlx_modem[504]: only_bridges routed connectons exist
Jan 1 03:01:21 triggerPingRespond[504]: OK
Jan 1 03:01:21 update_igmpx[504]: begin
Jan 1 03:01:21 get_gr_name_by_l3_key[504]: start
Jan 1 03:01:21 update_igmpx[504]: igmpx cfg: upstream list empty downstream list empty
Jan 1 03:01:21 stop_igmpx[504]: stop igmpx
Jan 1 03:01:21 stop_process_t[504]: not found pid process ‘igmpx’
Jan 1 03:01:21 resident[504]: stopped link(contype:ppp, iface:vc1_1)
Jan 1 03:01:21 after_stop_pppd[504]:
Jan 1 03:01:21 before_start_pppd[504]:
Jan 1 03:01:22 udhcpc[535]: Sending discover…
Jan 1 03:01:23 start_pppd[504]: using old session parameters: 3337:3C:94:D5:01:48:00
Jan 1 03:01:23 pppd[582]: Plugin /usr/lib/pppd/rp-pppoe.so loaded.
Jan 1 03:01:23 pppd[583]: pppd 2.4.4 started by admin, uid 0
Jan 1 03:01:26 start_stop_wan_link_on_l2[504]: End iface: vc1, status: 1
Jan 1 03:01:26 get_gr_name_by_l3_key[504]: start
Jan 1 03:01:26 get_gr_name_by_l3_key[504]: br0
Jan 1 03:01:26 get_gr_name_by_l3_key[504]: start
Jan 1 03:01:26 get_gr_name_by_l3_key[504]: br0
Jan 1 03:01:26 resident[216]: resident_ipoe_handler — l2:vc0, l3:vc0_1, tun:, ip_type:0
Jan 1 03:01:26 resident[216]: ip_is_down on vc0_1
Jan 1 03:01:26 resident_ipoe_handler[216]: is done on iface vc0_1 with action down
Jan 1 03:01:26 resident_ipoe_handler[216]: exit
Jan 1 03:01:26 udhcpc[535]: Sending discover…
Jan 1 03:01:30 pppd[583]: Sent PADT
Jan 1 03:01:30 pppoe-relay[595]: PADO packet from 3c:94:d5:01:4c:d4 on interface vc1 does not have Relay-Session-Id tag
Jan 1 03:01:30 pppoe-relay[595]: PADO packet from 4c:96:14:ab:64:82 on interface vc1 does not have Relay-Session-Id tag
Jan 1 03:01:30 pppoe-relay[595]: PADO packet from 3c:94:d5:01:48:00 on interface vc1 does not have Relay-Session-Id tag
Jan 1 03:01:30 pppoe-relay[595]: PADO packet from 4c:96:14:ab:64:d4 on interface vc1 does not have Relay-Session-Id tag
Jan 1 03:01:30 pppoe-relay[595]: PADS packet from 3c:94:d5:01:4c:d4 on interface vc1 does not have Relay-Session-Id tag
Jan 1 03:01:30 pppd[583]: PPP session is 32871
Jan 1 03:01:30 pppd[583]: Used ACName = «KRDR-BRAS6» in ppp(0)
Jan 1 03:01:30 kernel: Enter _rtl865x_attachMasterNetif (slave : ppp0 master : vc1)
Jan 1 03:01:30 kernel: (_rtl865x_attachMasterNetif) slave_netif : ppp0
Jan 1 03:01:30 kernel: (_rtl865x_attachMasterNetif) master_netif : NULL
Jan 1 03:01:30 kernel: Leave _rtl865x_attachMasterNetif @ 392
Jan 1 03:01:30 kernel: _rtl865x_getVlanFilterDatabaseId(336):the vlan is invalid!!!BUG!!!!
Jan 1 03:01:30 pppd[583]: Using interface ppp0
Jan 1 03:01:30 pppd[583]: Connect: ppp0 <—> vc1
Jan 1 03:01:30 resident_ppp_handler[614]: record = action:acname;iface:ppp0;acname:KRDR-BRAS6;link:vc1_1;
Jan 1 03:01:30 resident_ppp_handler[614]: Set default type: ipv4
Jan 1 03:01:30 resident_ppp_handler[614]: l2:vc1, l3:vc1_1, tun:||
Jan 1 03:01:31 pppd[583]: PAP authentication succeeded
Jan 1 03:01:31 pppd[583]: peer from calling number 3C:94:D5:01:4C:D4 authorized
Jan 1 03:01:31 pppd[583]: local IP address 100.66.185.94
Jan 1 03:01:31 pppd[583]: remote IP address 178.34.128.9
Jan 1 03:01:31 pppd[583]: primary DNS address 85.175.46.130
Jan 1 03:01:31 pppd[583]: secondary DNS address 85.175.46.122
Jan 1 03:01:31 resident_ppp_handler[618]: record = action:up;iface:ppp0;link:vc1_1;ipaddr:100.66.185.94;netmask:255.255.255.255;gateway:178.34.128.9;dns1:85.175.46.130;dns2:85.175.46.122;sess_id:32871:3C:94:D5:01:4C:D4;gw_mac:3C:94:D5:01:4C:D4;
Jan 1 03:01:31 resident_ppp_handler[618]: Set default type: ipv4
Jan 1 03:01:31 resident_ppp_handler[618]: l2:vc1, l3:vc1_1, tun:||
Jan 1 03:01:31 resident[618]: ppp_is_up on vc1_1
Jan 1 03:01:31 DMS_NL_API[618]: Rtnetlink answer: Success
Jan 1 03:01:31 DMS_ROUTE_SUCCESS[618]: DEL 178.34.128.9 via (null) dev ppp0 metr 0 table 254 (ppp_is_up)
Jan 1 03:01:31 DMS_NL_API[618]: Rtnetlink answer: Success
Jan 1 03:01:31 DMS_ROUTE_SUCCESS[618]: ADD default via (null) dev ppp0 metr 50 table 254 (ppp_is_up)
Jan 1 03:01:31 DMS_NL_API[618]: Rtnetlink answer: Success
Jan 1 03:01:31 DMS_ROUTE_SUCCESS[618]: ADD default via (null) dev ppp0 metr 50 table 253 (ppp_is_up)
Jan 1 03:01:31 get_gr_name_by_l3_key[618]: start
Jan 1 03:01:31 get_gr_name_by_l3_key[618]: br0
Jan 1 03:01:31 get_gr_index[618]: gr=|0|
Jan 1 03:01:31 DMS_NL_API[618]: Rtnetlink answer: Success
Jan 1 03:01:31 DMS_ROUTE_SUCCESS[618]: DEL default via (null) dev (null) metr 0 table 254 (wan_iptables_rules)
Jan 1 03:01:31 DMS_NL_API[618]: Rtnetlink answer: Success
Jan 1 03:01:31 DMS_ROUTE_SUCCESS[618]: ADD default via (null) dev ppp0 metr 0 table 254 (wan_iptables_rules)
Jan 1 03:01:31 rlx_modem[618]: only_bridges routed connectons exist
Jan 1 03:01:31 triggerPingRespond[618]: OK
Jan 1 03:01:31 update_ripd[618]: update rip
Jan 1 03:01:31 update_igmpx[618]: begin
Jan 1 03:01:31 get_gr_name_by_l3_key[618]: start
Jan 1 03:01:31 update_igmpx[618]: igmpx cfg: upstream list empty downstream list empty
Jan 1 03:01:31 stop_igmpx[618]: stop igmpx
Jan 1 03:01:31 stop_process_t[618]: not found pid process ‘igmpx’
Jan 1 03:01:31 update_ntpclient[618]: start
Jan 1 03:01:31 update_ntpclient[618]: server string: ntpd -S /sbin/ntpevent -p pool.ntp.org&
Jan 1 03:01:31 update_wan_firewall[618]: firewall enable
Jan 1 03:01:31 recheck_dnsmasq[618]: MD5 sums of /tmp/dnsmasq.conf are equal, not restarting DNSMASQ
Jan 1 03:01:32 autoupdate[618]: Downloading file: fwupdate.dlink.ru/dislocation
Jan 1 03:01:32 autoupdate[618]: Downloading file: fwupdate.dlink.ru/xDSL/DSL-2640U_RB_U2A_8M/Firmware/exclude
Jan 1 03:01:32 autoupdate[618]: Not found exception
Jan 1 03:01:32 autoupdate[618]: Downloading file: fwupdate.dlink.ru/xDSL/DSL-2640U_RB_U2A_8M/Firmware/latest
Jan 1 03:01:33 autoupdate[618]: Downloading file: fwupdate.dlink.ru/xDSL/DSL-2640U_RB_U2A_8M/Firmware/2017.07.13-15.31_DSL_2640RTL_S_8M_B_3.0.0_release.des
Jan 1 03:01:33 autoupdate[618]: Update not needed
Jan 1 03:01:39 udhcpc[535]: Sending discover…
Feb 11 10:46:56 udhcpc[535]: Sending discover…
Feb 11 10:46:56 dms_etherwan_read[689]: start
Feb 11 10:46:56 dms_get_etherwan_port[689]: start
Feb 11 10:46:56 dms_get_etherwan_port[689]: end: etherwan port 0
Feb 11 10:46:56 dms_get_etherwan_port_info[689]: start 1
Feb 11 10:46:56 dms_get_etherwan_port_info[689]: end
Feb 11 10:46:56 get_gr_name_by_lan_key[689]: start
Feb 11 10:46:56 get_gr_name_by_lan_key[689]: eth0.5: br0
Feb 11 10:46:56 dms_get_etherwan_port_info[689]: start 2
Feb 11 10:46:56 dms_get_etherwan_port_info[689]: end
Feb 11 10:46:56 get_gr_name_by_lan_key[689]: start
Feb 11 10:46:56 get_gr_name_by_lan_key[689]: eth0.4: br0
Feb 11 10:46:56 dms_get_etherwan_port_info[689]: start 3
Feb 11 10:46:56 dms_get_etherwan_port_info[689]: end
Feb 11 10:46:56 get_gr_name_by_lan_key[689]: start
Feb 11 10:46:56 get_gr_name_by_lan_key[689]: eth0.3: br0
Feb 11 10:46:56 dms_get_etherwan_port_info[689]: start 4
Feb 11 10:46:56 dms_get_etherwan_port_info[689]: end
Feb 11 10:46:56 get_gr_name_by_lan_key[689]: start
Feb 11 10:46:56 get_gr_name_by_lan_key[689]: eth0.2: br0
Feb 11 10:46:56 dms_etherwan_read[689]: end
Feb 11 10:46:56 adsl_status[691]: 1950
Feb 11 10:46:57 adsl_status[702]: 1950
Feb 11 10:46:57 dms_etherwan_read[710]: start
Feb 11 10:46:57 dms_get_etherwan_port[710]: start
Feb 11 10:46:57 dms_get_etherwan_port[710]: end: etherwan port 0
Feb 11 10:46:57 dms_get_etherwan_port_info[710]: start 1
Feb 11 10:46:57 dms_get_etherwan_port_info[710]: end
Feb 11 10:46:57 get_gr_name_by_lan_key[710]: start
Feb 11 10:46:57 get_gr_name_by_lan_key[710]: eth0.5: br0
Feb 11 10:46:57 dms_get_etherwan_port_info[710]: start 2
Feb 11 10:46:57 dms_get_etherwan_port_info[710]: end
Feb 11 10:46:57 get_gr_name_by_lan_key[710]: start
Feb 11 10:46:57 get_gr_name_by_lan_key[710]: eth0.4: br0
Feb 11 10:46:57 dms_get_etherwan_port_info[710]: start 3
Feb 11 10:46:57 dms_get_etherwan_port_info[710]: end
Feb 11 10:46:57 get_gr_name_by_lan_key[710]: start
Feb 11 10:46:57 get_gr_name_by_lan_key[710]: eth0.3: br0
Feb 11 10:46:57 dms_get_etherwan_port_info[710]: start 4
Feb 11 10:46:57 dms_get_etherwan_port_info[710]: end
Feb 11 10:46:57 get_gr_name_by_lan_key[710]: start
Feb 11 10:46:57 get_gr_name_by_lan_key[710]: eth0.2: br0
Feb 11 10:46:57 dms_etherwan_read[710]: end
Feb 11 10:46:57 adsl_status[712]: 1950
Feb 11 10:46:57 adsl_status[717]: 1950
Feb 11 10:47:00 udhcpc[535]: Sending discover…
Feb 11 10:47:01 dms_etherwan_read[740]: start
Feb 11 10:47:01 dms_get_etherwan_port[740]: start
Feb 11 10:47:01 dms_get_etherwan_port[740]: end: etherwan port 0
Feb 11 10:47:01 dms_get_etherwan_port_info[740]: start 1
Feb 11 10:47:01 dms_get_etherwan_port_info[740]: end
Feb 11 10:47:01 get_gr_name_by_lan_key[740]: start
Feb 11 10:47:01 get_gr_name_by_lan_key[740]: eth0.5: br0
Feb 11 10:47:01 dms_get_etherwan_port_info[740]: start 2
Feb 11 10:47:01 dms_get_etherwan_port_info[740]: end
Feb 11 10:47:01 get_gr_name_by_lan_key[740]: start
Feb 11 10:47:01 get_gr_name_by_lan_key[740]: eth0.4: br0
Feb 11 10:47:01 dms_get_etherwan_port_info[740]: start 3
Feb 11 10:47:01 dms_get_etherwan_port_info[740]: end
Feb 11 10:47:01 get_gr_name_by_lan_key[740]: start
Feb 11 10:47:01 get_gr_name_by_lan_key[740]: eth0.3: br0
Feb 11 10:47:01 dms_get_etherwan_port_info[740]: start 4
Feb 11 10:47:01 dms_get_etherwan_port_info[740]: end
Feb 11 10:47:01 get_gr_name_by_lan_key[740]: start
Feb 11 10:47:01 get_gr_name_by_lan_key[740]: eth0.2: br0
Feb 11 10:47:01 dms_etherwan_read[740]: end
Feb 11 10:47:01 adsl_status[743]: 1950
Feb 11 10:47:01 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:0
Feb 11 10:47:01 pppd[583]: System time change detected.
Feb 11 10:47:01 pppd[583]: write: Bad address (14)
Feb 11 10:47:01 adsl_status[748]: 1950
Feb 11 10:47:05 update_ntpclient_periodic[766]: date is set, switching off periodic update.
Feb 11 10:47:05 autoupdate[763]: Downloading file: fwupdate.dlink.ru/dislocation
Feb 11 10:47:05 autoupdate[763]: Downloading file: fwupdate.dlink.ru/xDSL/DSL-2640U_RB_U2A_8M/Firmware/exclude
Feb 11 10:47:05 autoupdate[763]: Not found exception
Feb 11 10:47:05 autoupdate[763]: Downloading file: fwupdate.dlink.ru/xDSL/DSL-2640U_RB_U2A_8M/Firmware/latest
Feb 11 10:47:06 autoupdate[763]: Downloading file: fwupdate.dlink.ru/xDSL/DSL-2640U_RB_U2A_8M/Firmware/2017.07.13-15.31_DSL_2640RTL_S_8M_B_3.0.0_release.des
Feb 11 10:47:06 autoupdate[763]: Update not needed
Feb 11 10:47:13 udhcpc[728]: Sending discover…
Feb 11 10:47:15 udhcpc[728]: Sending discover…
Feb 11 10:47:19 udhcpc[728]: Sending discover…
Feb 11 10:47:31 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:1
Feb 11 10:47:31 pppd[583]: write: Bad address (14)
Feb 11 10:47:32 udhcpc[728]: Sending discover…
Feb 11 10:47:34 udhcpc[728]: Sending discover…
Feb 11 10:47:38 udhcpc[728]: Sending discover…
Feb 11 10:48:01 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:2
Feb 11 10:48:01 pppd[583]: write: Bad address (14)
Feb 11 10:48:31 pppd[583]: write: Bad address (14)
Feb 11 10:48:31 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:3
Feb 11 10:48:42 udhcpc[728]: Sending discover…
Feb 11 10:48:44 udhcpc[728]: Sending discover…
Feb 11 10:48:48 udhcpc[728]: Sending discover…
Feb 11 10:49:01 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:4
Feb 11 10:49:01 pppd[583]: write: Bad address (14)
Feb 11 10:49:32 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:5
Feb 11 10:49:32 pppd[583]: write: Bad address (14)
Feb 11 10:49:52 udhcpc[728]: Sending discover…
Feb 11 10:49:54 udhcpc[728]: Sending discover…
Feb 11 10:49:58 udhcpc[728]: Sending discover…
Feb 11 10:50:02 pppd[583]: write: Bad address (14)
Feb 11 10:50:02 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:6
Feb 11 10:50:31 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:7
Feb 11 10:50:31 pppd[583]: write: Bad address (14)
Feb 11 10:51:02 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:8
Feb 11 10:51:02 pppd[583]: write: Bad address (14)
Feb 11 10:51:03 udhcpc[728]: Sending discover…
Feb 11 10:51:05 udhcpc[728]: Sending discover…
Feb 11 10:51:09 udhcpc[728]: Sending discover…
Feb 11 10:52:02 pppd[583]: write: Bad address (14)
Feb 11 10:52:02 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:10
Feb 11 10:52:13 udhcpc[728]: Sending discover…
Feb 11 10:52:15 udhcpc[728]: Sending discover…
Feb 11 10:52:19 udhcpc[728]: Sending discover…
Feb 11 10:52:32 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:11
Feb 11 10:52:32 pppd[583]: write: Bad address (14)
Feb 11 10:53:02 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:12
Feb 11 10:53:02 pppd[583]: write: Bad address (14)
Feb 11 10:53:23 udhcpc[728]: Sending discover…
Feb 11 10:53:25 udhcpc[728]: Sending discover…
Feb 11 10:53:29 udhcpc[728]: Sending discover…
Feb 11 10:53:32 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:13
Feb 11 10:53:32 pppd[583]: write: Bad address (14)
Feb 11 10:54:02 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:14
Feb 11 10:54:02 pppd[583]: write: Bad address (14)
Feb 11 10:54:32 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:15
Feb 11 10:54:32 pppd[583]: write: Bad address (14)
Feb 11 10:54:32 udhcpc[728]: Sending discover…
Feb 11 10:54:34 udhcpc[728]: Sending discover…
Feb 11 10:54:38 udhcpc[728]: Sending discover…
Feb 11 10:55:02 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:16
Feb 11 10:55:02 pppd[583]: write: Bad address (14)
Feb 11 10:55:32 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:17
Feb 11 10:55:32 pppd[583]: write: Bad address (14)
Feb 11 10:55:42 udhcpc[728]: Sending discover…
Feb 11 10:55:44 udhcpc[728]: Sending discover…
Feb 11 10:55:48 udhcpc[728]: Sending discover…
Feb 11 10:56:32 pppd[583]: write: Bad address (14)
Feb 11 10:56:32 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:19
Feb 11 10:56:52 udhcpc[728]: Sending discover…
Feb 11 10:56:54 udhcpc[728]: Sending discover…
Feb 11 10:56:58 udhcpc[728]: Sending discover…
Feb 11 10:57:31 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:21
Feb 11 10:57:31 pppd[583]: write: Bad address (14)
Feb 11 10:58:01 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:22
Feb 11 10:58:01 pppd[583]: write: Bad address (14)
Feb 11 10:58:02 udhcpc[728]: Sending discover…
Feb 11 10:58:04 udhcpc[728]: Sending discover…
Feb 11 10:58:08 udhcpc[728]: Sending discover…
Feb 11 10:58:31 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:23
Feb 11 10:58:31 pppd[583]: write: Bad address (14)
Feb 11 10:59:02 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:24
Feb 11 10:59:02 pppd[583]: write: Bad address (14)
Feb 11 10:59:13 udhcpc[728]: Sending discover…
Feb 11 10:59:15 udhcpc[728]: Sending discover…
Feb 11 10:59:19 udhcpc[728]: Sending discover…
Feb 11 11:00:02 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:26
Feb 11 11:00:02 pppd[583]: write: Bad address (14)
Feb 11 11:00:23 udhcpc[728]: Sending discover…
Feb 11 11:00:25 udhcpc[728]: Sending discover…
Feb 11 11:00:29 udhcpc[728]: Sending discover…
Feb 11 11:00:32 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:27
Feb 11 11:00:32 pppd[583]: write: Bad address (14)
Feb 11 11:01:02 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:28
Feb 11 11:01:02 pppd[583]: write: Bad address (14)
Feb 11 11:01:32 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:29
Feb 11 11:01:32 pppd[583]: write: Bad address (14)
Feb 11 11:01:33 udhcpc[728]: Sending discover…
Feb 11 11:01:35 udhcpc[728]: Sending discover…
Feb 11 11:01:39 udhcpc[728]: Sending discover…
Feb 11 11:02:02 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:30
Feb 11 11:02:02 pppd[583]: write: Bad address (14)
Feb 11 11:02:32 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:31
Feb 11 11:02:32 pppd[583]: write: Bad address (14)
Feb 11 11:02:42 udhcpc[728]: Sending discover…
Feb 11 11:02:44 udhcpc[728]: Sending discover…
Feb 11 11:02:48 udhcpc[728]: Sending discover…
Feb 11 11:03:02 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:32
Feb 11 11:03:02 pppd[583]: write: Bad address (14)
Feb 11 11:03:04 anweb[224]: check need_redirect started
Feb 11 11:03:04 anweb[224]: need_redirect: is defconf
Feb 11 11:03:04 anweb[225]: check need_redirect started
Feb 11 11:03:04 anweb[225]: need_redirect: is defconf
Feb 11 11:03:15 dms_etherwan_read[1545]: start
Feb 11 11:03:15 dms_get_etherwan_port[1545]: start
Feb 11 11:03:15 dms_get_etherwan_port[1545]: end: etherwan port 0
Feb 11 11:03:15 dms_get_etherwan_port_info[1545]: start 1
Feb 11 11:03:15 dms_get_etherwan_port_info[1545]: end
Feb 11 11:03:15 get_gr_name_by_lan_key[1545]: start
Feb 11 11:03:15 get_gr_name_by_lan_key[1545]: eth0.5: br0
Feb 11 11:03:15 dms_get_etherwan_port_info[1545]: start 2
Feb 11 11:03:15 dms_get_etherwan_port_info[1545]: end
Feb 11 11:03:15 get_gr_name_by_lan_key[1545]: start
Feb 11 11:03:15 get_gr_name_by_lan_key[1545]: eth0.4: br0
Feb 11 11:03:15 dms_get_etherwan_port_info[1545]: start 3
Feb 11 11:03:15 dms_get_etherwan_port_info[1545]: end
Feb 11 11:03:15 get_gr_name_by_lan_key[1545]: start
Feb 11 11:03:15 get_gr_name_by_lan_key[1545]: eth0.3: br0
Feb 11 11:03:15 dms_get_etherwan_port_info[1545]: start 4
Feb 11 11:03:15 dms_get_etherwan_port_info[1545]: end
Feb 11 11:03:15 get_gr_name_by_lan_key[1545]: start
Feb 11 11:03:15 get_gr_name_by_lan_key[1545]: eth0.2: br0
Feb 11 11:03:15 dms_etherwan_read[1545]: end
Feb 11 11:03:15 adsl_status[1552]: 1950
Feb 11 11:03:32 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:33
Feb 11 11:03:32 pppd[583]: write: Bad address (14)
Feb 11 11:03:52 udhcpc[728]: Sending discover…
Feb 11 11:03:54 udhcpc[728]: Sending discover…
Feb 11 11:03:58 udhcpc[728]: Sending discover…
Feb 11 11:04:02 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:34
Feb 11 11:04:02 pppd[583]: write: Bad address (14)
Feb 11 11:04:32 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:35
Feb 11 11:04:32 pppd[583]: write: Bad address (14)
Feb 11 11:05:02 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:36
Feb 11 11:05:02 pppd[583]: write: Bad address (14)
Feb 11 11:05:02 udhcpc[728]: Sending discover…
Feb 11 11:05:04 udhcpc[728]: Sending discover…
Feb 11 11:05:08 udhcpc[728]: Sending discover…
Feb 11 11:06:02 pppd[583]: write: Bad address (14)
Feb 11 11:06:02 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:38
Feb 11 11:06:13 udhcpc[728]: Sending discover…
Feb 11 11:06:15 udhcpc[728]: Sending discover…
Feb 11 11:06:19 udhcpc[728]: Sending discover…
Feb 11 11:06:32 pppd[583]: write: Bad address (14)
Feb 11 11:06:32 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:39
Feb 11 11:07:02 pppd[583]: write: Bad address (14)
Feb 11 11:07:02 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:40
Feb 11 11:07:23 udhcpc[728]: Sending discover…
Feb 11 11:07:25 udhcpc[728]: Sending discover…
Feb 11 11:07:29 udhcpc[728]: Sending discover…
Feb 11 11:07:32 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:41
Feb 11 11:07:32 pppd[583]: write: Bad address (14)
Feb 11 11:08:02 pppd[583]: write: Bad address (14)
Feb 11 11:08:02 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:42
Feb 11 11:08:32 kernel: in func<pppoe_rcv>, LCP reply send in protocol stack sid:32871, id:43
Feb 11 11:08:32 pppd[583]: write: Bad address (14)
Feb 11 11:08:33 udhcpc[728]: Sending discover…
Feb 11 11:08:35 udhcpc[728]: Sending discover…
Feb 11 11:08:39 udhcpc[728]: Sending discover..
Process pid not found?
Not sure where I’m going wrong here (using 3.3):
pid = os.getpid()
p = psutil.Process(pid)
Works OK in WinXP, but fails with ‘no process found with pid 1351’ (an example value) on PA.
Ta,
Jim
deleted-user-97248
|
391
posts
|
Aug. 22, 2013, 3:44 p.m.
|
permalink
Traceback (most recent call last):
File "/usr/local/lib/python3.3/dist-packages/psutil/_pslinux.py", line 430, in wrapper
return fun(self, *args, **kwargs)
File "/usr/local/lib/python3.3/dist-packages/psutil/_pslinux.py", line 560, in get_process_create_time
f = open("/proc/%s/stat" % self.pid)
FileNotFoundError: [Errno 2] No such file or directory: '/proc/1509/stat'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.3/dist-packages/psutil/__init__.py", line 158, in __init__
self.create_time
File "/usr/local/lib/python3.3/dist-packages/psutil/_common.py", line 80, in __get__
ret = self.func(instance)
File "/usr/local/lib/python3.3/dist-packages/psutil/__init__.py", line 378, in create_time
return self._platform_impl.get_process_create_time()
File "/usr/local/lib/python3.3/dist-packages/psutil/_pslinux.py", line 437, in wrapper
raise NoSuchProcess(self.pid, self._process_name)
psutil._error.NoSuchProcess: process no longer exists (pid=1509)
deleted-user-97248
|
391
posts
|
Aug. 22, 2013, 3:46 p.m.
|
permalink
I don’t think that’s going to work on PythonAnywhere, at least as the system is right now.
Your processes can actually be running on any one of quite a large cluster of machines, so normal Linux process management doesn’t work for almost any normal case. Of course, in your specific case, because you’re trying to get the details of the current process, it is guaranteed to be running on the same machine as itself, but we’ve been avoiding adding support for the process module just because we think it would be a bad idea to provide something that sometimes worked but normally didn’t.
Perhaps there’s some other way to get the information you need — what are you trying to get the psutil.Process object for?
giles
|
11163
posts
|
PythonAnywhere staff
|
Aug. 22, 2013, 4:32 p.m.
|
permalink
Many thanks Giles.
I’m pretty sure there’s an easier way to do what I want anyway — I just want to check in a Scheduled job whether or not a program is already running (and restart it if it isn’t).
So I was going to look at other processes and see if there was a ‘python3.3’ running the same file.
What’s a better PA pattern for this please?
Jim
deleted-user-97248
|
391
posts
|
Aug. 22, 2013, 9:24 p.m.
|
permalink
I assume the program you want to be running is one that you normally run from a console?
The best thing to do is probably to convert it to be run by a scheduled task, which runs once an hour or once a day, and either (re)launches the job if it’s not running, or just quits if it is already running.
Then you just need some way of checking whether the process is running. We often use a socket for these cases. Your process opens the socket while it runs, and if it ever exits, it will release it automatically. Then it’s easy to check on, with code like this:
import logging
import socket
import sys
from my_module import my_long_running_process
lock_socket = socket.socket(socket.AF_UNIX, socket.SOCK_DGRAM)
try:
lock_id = "my-username.my-task-name" # this should be unique. using your username as a prefix is a convention
lock_socket.bind('' + lock_id)
logging.debug("Acquired lock %r" % (lock_id,))
except socket.error:
# socket already locked, task must already be running
logging.info("Failed to acquire lock %r" % (lock_id,))
sys.exit()
my_long_running_process()
harry
|
2710
posts
|
PythonAnywhere staff
|
Aug. 23, 2013, 10:22 a.m.
|
permalink
Looks good! A few comments, mainly to try and anticipate questions people might have reading it…
It might be helpful to clarify that you mean a Unix domain socket instead of just saying «socket», as anybody who’s done Internet sockets only may assume that’s what you mean and then be terribly confused that you’re not specifying an IP address and port number. May also be worth a brief mention that the nul-character prefix on the socket name is a Linux-specific extension, just for anybody who’s encountered Unix domain sockets on other systems but isn’t aware of the Linux-specific abstract namespace.
I guess it might also be worth clarifying the situation re the machine that scheduled tasks run on. For example, if a scheduled task ends up running on a different machine then the socket won’t be accessible (unless there’s some underlying magic which makes them available on other machines?). So, let’s say scheduled tasks for a given user are running on host A. Each time it sees the socket is still active and skips starting the process. Great so far. Now something happens which migrates scheduled tasks for that user to host B. The next time it runs it sees the socket is no longer open and hence starts a new instance of the process. Can we be sure that the other machine doesn’t still have an instance of the process running?
If scheduled jobs are only migrated just prior to a machine being fully shut down (including terminating all user processes) then this is probably not a big deal. If that’s not a certainty, however, it may be worth noting in the page because some users may have tasks which will cause corruption if run concurrently, so they should probably be made aware if they need to implement some sort of stronger locking (probably involving the filesystem).
As a point of interest, I was idly considering the other day if it’s possible to do proper locking without assumptions about OS-level lock primitives and the like and I was trying to dredge up memory of distributed mutex algorithms from University. I had some thoughts on it, but I wouldn’t want to pollute this thread with them — I’ll write a blog post about it if I get the time, and people can rip it apart! (^_^)
deleted-user-39880
|
669
posts
|
Aug. 23, 2013, 1:44 p.m.
|
permalink
Many thanks both — food for thought!
@harry Yes, currently I start it from a console.
I guess the original problem is in the general area of IPC (Inter-Process Communication), so there are many other ways e.g. using disk files or OS features like shared memory, semaphores etc. But in the PA multi-processor situation mentioned by both giles and Cartroo, I wonder how many options are still available?
deleted-user-97248
|
391
posts
|
Aug. 23, 2013, 3:29 p.m.
|
permalink
Your problem is that you never know what server any given piece of code is going to run on, so you can’t be sure that any two processes are on the same machine.
You have two possible tools to support synchronisation, the filesystem (your /home and /tmp are shared via NFS) and a database. Of the two, the database is probably the most reliable, since NFS can be a bit iffey about consistency, unlike MySQL whose bread and butter is the whole ACID thing. Sqlite, of course, would be on NFS so it ends up with the same disadvantages.
harry
|
2710
posts
|
PythonAnywhere staff
|
Aug. 23, 2013, 4:20 p.m.
|
permalink
MySQL would work well, although you have to do a little work to check the liveness of the process to coe with the fact that its terminated ungracefully — this could happen due to a bug, a crash or hardware failure.
If you’re going to go the MySQL route (and I agree this does make certain aspects easier, like atomicity) then you’d either need to do something fancy by listing active connections (which I wouldn’t suggest) or do something like periodically update the database to indicate liveness — I’ll describe an idea for such a procedure below.
When a proces starts up it creates a row in a «processes» table with an AUTO_INCREMENT column to assign it a unique ID. Every N seconds it executes a DROP statement for all rows with an ID higher than its own and also checks whether its own row still exists — if it ever finds its own row has been removed, it exits immediately.
When the process first starts, it needs to check whether any existing process is still running. This involves a delay so I suggest still forking away from th scheduled task itself before doing this. The process creates its own row and then waits 2N seconds. If it finds its own row has been deleted then it can be certain tha there’s an actively running process with a lower ID, so it can exit.
If it finds its own row still extant then any process with a lower ID must be dead so DROP any such row and then go into active running. You may wish to track the «waiting» vs. «running» state with an additionl enumeration column for diagnostic purposes, and I would also suggest additional columns for the hostname and PID. Once it’s running it proceeds as above, removing rows created by competing processes trying to detect if it’s still running. If the process ever crashes or hangs, it will no longer remove competing rows and hence eventually be removed itself.
Instead of removing rows you could intead set their state to «dead» and that would allow you to manually check for tasks hanging around and terminate them appropriately.
That might seem a complex approach for a simple problem, but I can’t think of anything much simpler which doesn’t assume running on the same host and doesn’t risk multiple instances running concurrently.
deleted-user-39880
|
669
posts
|
Aug. 25, 2013, 8:48 a.m.
|
permalink
@harry @Cartroo Many thanks both — great ecosystem here on PA!
I was hoping to use a simpler approach in MySQL with LOCK TABLES, e.g. http://dev.mysql.com/doc/refman/5.0/en/lock-tables.html — do you think this may be feasible? The lock(s) are released when the process / MySQL session terminates, either normally or abnormally (or of course on UNLOCK TABLES).
But I’m not sure if there’s a non-blocking way in MySQL to test if a table is already locked, or does it always wait?
Also, can I assume that each of my processes has a separate MySQL session?
Ta,
Jim
deleted-user-97248
|
391
posts
|
Aug. 25, 2013, 6:21 p.m.
|
permalink
Yes, you could use locks — that’s not a bad idea.
I think you’d want to use named locks rather than LOCK TABLES — see GET_LOCK() for lock acquiry with a timeout. However, I’m not sure if PA users have the relevant permissions to use them. Also be aware that names are server-wide so prefix names with your username.
EDIT:
So I just did a quick test and GET_LOCK() seems to work as expected. Remember what I said about prefixing lock names with your username, or some other string you’re certain is unique. I would suggest something like username.appname.lockname, so if I had an application called feedscraper then my code might include this snippet:
def current_instance(cur):
cur.execute("SELECT GET_LOCK('cartroo.feedscraper.running')")
row = cur.fetchone()
return (row and row[0])
def main(argv):
# ...
conn = MySQLdb.connect(...)
cur = conn.cursor()
if not current_instance(cur):
return 1
# ...
if __name__ == "__main__":
sys.exit(main(sys.argv))
Also remember that these named locks are connection-oriented — they’re automatically released when the connection closes. They can also be explicitly released prior to this with RELEASE_LOCK(), but if you want the lock held over the lifetime of your application then you shouldn’t need this. So, make sure you keep your connection alive — sending MySQL pings is useful for this. If you find your connection isn’t alive when you ping, make sure you re-acquire the lock when you’ve re-created your connection — if the lock has been taken by someone else in the small gap, that process will have to exit.
One useful non-obvious feature is that lock acquiry is idempotent, so you can safely attempt to re-acquire a lock you already hold. This is a useful way to confirm that you still hold the lock. You can also use IS_FREE_LOCK() for this purpose, though of course you still have to check the result of a subsequent GET_LOCK() to avoid a race condition, so you might as well just GET_LOCK() in the first place.
One potentially less useful non-obvious feature is that a connection can only hold a single named lock at a time — calling GET_LOCK() on a different name when an earlier lock is already held performs an implicit RELEASE_LOCK() on that earlier lock. If you’re already using GET_LOCK() elsewhere in your application then you can still get an additional lock but you’ll need to make sure you use a separate MySQL connection for it (since locks are connection-specific).
deleted-user-39880
|
669
posts
|
Aug. 25, 2013, 10:21 p.m.
|
permalink
@Cartroo Many thanks! Sorry for the delay — ‘day job’ intruded…
I’ll have a go at this when I can and get back to you. Has there been any talk of a PA library, e.g. including this?
Jim
deleted-user-97248
|
391
posts
|
Aug. 29, 2013, 8:06 a.m.
|
permalink
You’re quite welcome. I know what you mean about the day job, I don’t get nearly as much time to help out here as I’d like since I changed jobs.
I’m not aware of any discussion of a «pawutils» library — I guess it might be somewhat tricky because everyone’s needs differ slightly. However, there’s probably value in collecting together some best practice functions and classes for convenience and making them available in the environment. At least it would give people something to base their own code on if nothing else.
I suspect the main cost would be maintenance, but perhaps if the PA admins approve of the idea but don’t feel they can commit the time to maintain it themselves, they could create a public repository on Github and allow the community to share some of the burden. It’s unlikely that anything in the library would be particularly commercially sensitive, given the public nature of the PA platform. If they find it easier for installation they could even stick it on PyPI, I suppose!
@PA boffins: thoughts?
deleted-user-39880
|
669
posts
|
Aug. 29, 2013, 8:58 a.m.
|
permalink
That’s an neat idea! We’re working on putting as much as we can into the help pages at the moment, but perhaps we could create a public repo with some of the more generally useful ones in it. What else do you think would be a good candidate to add?
giles
|
11163
posts
|
PythonAnywhere staff
|
Aug. 29, 2013, 10:57 a.m.
|
permalink
Thanks both! Maybe one of you could start a new forum topic (with a more appropriate name!) and invite ideas?
My immediate thought is anything that would help with the multi-process instance(s) discussed above — a bit like a psutils+ or something, perhaps using MySQL to store ‘global’ process info for a user. But I don’t have a feel yet for the most common issues affecting other folk.
deleted-user-97248
|
391
posts
|
Aug. 29, 2013, 11:33 a.m.
|
permalink
Excellent idea, I’ll start a topic now.
giles
|
11163
posts
|
PythonAnywhere staff
|
Aug. 29, 2013, 12:23 p.m.
|
permalink
Returning to this issue of detecting whether or not ‘my program XX is already running’ and the useful discussion above about different approaches to locking etc., is it possible that PAW already has the answer in its own code?
Does the PAW code have a complete picture of both Bash shell activity and Scheduled job activity for each user, that could potentially be accessed via a new API?
At its simplest, a user could then in a scheduled job say something like: only start XX if no other job is running XX.
deleted-user-97248
|
391
posts
|
Sept. 17, 2013, 7:50 a.m.
|
permalink
Does the PAW code have a complete picture of both Bash shell activity and Scheduled job activity for each user,
Nope! Or at least, not explicitly, and not in a joined-up way. But we’re planning on building one…
harry
|
2710
posts
|
PythonAnywhere staff
|
Sept. 17, 2013, 11:34 a.m.
|
permalink
Ah, thanks harry!
Back to the MySQL approach for now, I guess…
deleted-user-97248
|
391
posts
|
Sept. 17, 2013, 11:40 a.m.
|
permalink
- Remove From My Forums
-
Question
-
I tried to profile a dll in by my Azure cloud service using instrumentation method. My web site only support https. Originally I tried «VSPerfAspNetCmd» but it seems it does not support https, so I have to use «VSPerfAspCmd» however
got «Error VSP1312: Process <PID> not found in list of active profile targets».I remotely login to the Azure VM, and then ran the following commands from the «x64» folder of the performance tools (Visual Studio 2015).
1. Run «VSInstr <mydll>» to generate the instrumented dll in my site.
2. Run «VSPerfCLREnv.cmd /traceon» and «VSPerfCLREnv.cmd /globaltraceon», and then restart the VM.
I validated that the instrumented dll is correctly loaded by w3wp.exe process
3. Run «VSPerfCmd.exe /start:trace /output:c:myReport.vsp /cs /user:Everyone /ProcessOn:<PID of w3wp.exe>», but got error «Error VSP1312: Process <PID> not found in list of active profile targets».
Note that «w3wp.exe» is running under user «NT AuthorityNetwork Service» in session 0, but I am running the command with my own user name under a remote login session. That is the reason I specified «/user:Everyone» and «/cs»
in the «VSPerfCmd.exe» command line above, but still got the error.Does anyone know the cause?
Answers
-
I’ve figured it out. Hope it is helpful to anyone who encountered the same issue.
In step 3, remove «/processon:<pid>» but leave other options, this will just start the perf monitoring.
Then after that, restart w3wp service and it will then be recognized by the perf monitor.
You can verify that with «VsPerfCmd.exe /status» it will show «Number of Active Processes» as 1, and the w3wp.exe process and its thread will be also listed below.
Now with option «/processon» or «/processoff», you can resume/pause the collection on a process. Keep in mind that «/processon» will resume a paused collection, not to start a new collection.
— VsPerfCmd.exe /processon:<pid of w3wp>
— VsPerfCmd.exe /processoff:<pid of w3wp>
-
Marked as answer by
Monday, January 25, 2016 7:41 PM
-
Marked as answer by